Over the past few weeks I’ve been playing with the new ASP.NET 5 (also known as ASP.NET vNext) bits using Visual Studio 2015. I’m trying to make sense of the new changes and how they will affect how I build websites. I’d like to share some of what I’ve learned about the new stack.
I’m going to do this by talking through an example website I wrote using the new bits. Do know that we’re still pretty early and Visual Studio 2015 (CTP6 as of this writing) and ASP.NET 5 Beta 3 are both in a state of flux. This is definitely about what’s coming, not what is here so far.
If you've been following my blog, you should know that I am keeping a pretty close watch on ADO.NET Data Services. The team recently released a second CTP of the new version with some interesting features. This CTP has some pretty compelling additions, but I am going ot focus on one in particular.
I've been teaching and using ADO.NET Data Services for a long time and I like showing off exposing a LINQ-based provider (Entity Framework, NHibernate or others) to a Silverlight application. While ADO.NET Data Services does expose its API through a REST API, the magic for me is in its use in Silverlight. In case you haven't been following along, using the Silverlight client you can issue a LINQ query through the Silverlight client (though in fairness, the full power of LINQ is not supported in the client):
It all depends...
If you missed me in Bulgaria's DevReach conference, the video of my Silverlight Data Access talk is now available. The original talk's description was:
Today at 3pm CST (4pm EST, 1pm PST) I will be doing a LiveMeeting talk on ADO.NET Data Services. If you are not at the PDC this week, drop by NotAtPDC.com and check out my session!
There is a known problem with ADO.NET Data Services today that is important if you (or your server) lives in specific timezones. The problem is associated with the way that the Silverlight Data Services Library constructs their URI for searches.
The problem surfaces if you do a query that has a DateTime comparison in it. For example:
In building my Silverlight RC example using ADO.NET Data Services for Entity Framework and NHibernate I ran into what I think is a common pattern. I am writing an editor for XBox game data. The model for this data uses decorator tables in the database which are modeled as a common "Product" class and derived "Game", "Console" and "Accessory" classes. In the application I am using paging to only look at fifty results at once. This works fine on both sides.
But one of the pieces of information I wanted was a list of all the Game Genre. This became problematic as ADO.NET Data Services wanted me to retrieve all 880 games in order to get a list of these Genres (of which there are only 20 some odd). The whole idea of using paging is go avoid the huge overhead of bringing down the whole entity. Interestingly when I executed a LINQ query that used projection into non-entities, the query wasn't supported as projection isn't allowed in the ADO.NET Data Services URI model (which the client uses).
It seems that because of some internal NHibernate changes that are required to make NHibernate LINQ work really well, the current version of NHibernate LINQ will not be supported. Evidently there are a number of complex queries that do not work correctly under the current codebase. Its been announced that these changes will be made in the NHibernate 2.1 (which is in development). Follow the link to read the full details!
I've uploaded a new version of my code from my Silverlight 2/Data Services MSDN Article. I took the new Silverlight 2 Data Services client that was released and updated the code example. If you want to get the code, you can download it from my site here:
Mike Flasko to the rescue! The ADO.NET Data Services Team has released an interim build of the ADO.NET Data Services Library to address .NET 3.5 SP1 incompatibilities. While this is just a stop-gap measure, its of great relief that I announce this news as my new MSDN Magazine article was broken because of the incompatibility.
As some of you may have seen, my new article in MSDN Magazine (and online) was recently published. Because we're in a bit of a no-mans-land with builds, the current article only works with .NET 3.5 SP1 Beta and Silverlight 2 Beta 2. This means if you're like most of the world and updated to the full release of .NET 3.5 SP1, some of the code in that article is not going to work for you. I hope to have a new drop of the code (and maybe the article too) once Silverlight 2 ships and is fully compatible with ADO.NET Data Services/Entity Framework that are in the full version of .NET 3.5 SP1. See my other article talking about the incompatibilities here:
My new article on creating Silverlight 2 applications that use ADO.NET Data Services is in the new issue of MSDN Magazine. In this article I show you how to create a ADO.NET Data Service as well as how to call that service using the Silverlight 2 Data Service Library.
Data is a funny business. While at the moment I am spending a lot of time teaching Silverlight, my passion still lives in the data. I was brought up on Minisystems (Multi-user CP/M and the like) where you were dealing with something like a database (though we didn't have that as firm a concept as you might think). Later I did quite a lot of desktop database development starting with dBase II (yes, I am that old), Paradox, Clipper, FoxPro and even Access. That naturally led to client-server and N-Tier development. Throughout all the time its become exceptionally clear how much data matters to most applications.
But using databases can be difficult as there is an impedance mismatch with object-oriented development and the natural structure of data. The solution to this for many organizations has been to build data access and business object layers around the data. These layers were meant to simplify data access for most developers and embed the business logic directly into a re-usable set of code instead of it ending up in the UI layer. This was a good thing...
UPDATE: This may be incorrect. I am working with Microsoft to understand if I got this wrong. I'll update this blog once I get the story right.
To many developers this may seem odd. I talk with many staunch ALT.NET guys, and the DDD philosophy seems to be that data is a top-down or at worse, bottom up design problem. The issue here is that there is an assumption that just simply not true that data design is part of most software development projects. The reality based on my experience as well as the experience of talking with developers in the community is that many projects (though its hard to exactly quantify what percentage) begin with existing data. This is especially true in the enterprise where data exists in many forms from new databases, legacy servers (e.g. mainframes) or even flat files and XML. It is the rare project that is new code against all new data.
For new projects, creating a new database schema that at least in some part mimics the design of a project makes sense. The problem is that over time the data must evolve. I think the reality is that depending on the organization this can be very different. There are some opinions that I think impact the maturation of a data model:
The Entity Framework "No Confidence Vote" is a couple of days old now. I wanted to give the Internet a couple of days to chew it over and figure out where it really fit into the big picture. If you follow me on Twitter you may have seen some back and forth between Scott Belware and I recently. Most of this back and forth has been about his attacks of the Microsoft community (attacks of the technology or even the company are fair game as far as I am concerned). Getting personal by accusing me, the Microsoft community or even individual EF Team member's directly seems petty and unnecessary.
In that same light, some of the ALT.NET community (I won't name names) have accused me of being a shill for Microsoft's techologies. Anyone who has ever seen me talk about any Microsoft technology already knows that I pride myself in my centrist view of any technology (Microsoft's or others).
When I deployed the small test application (http://www.silverlightdata.com/simple), it was pretty apparent that it was performing really badly. Some of this is because my ISP upload speed isn't great but it was still taking far too long I thought. This was a simple app with not much data, so I knew I wanted to find out what was happening. If you haven't seen the site, its basically an editor for the Product table in the Northwind database. Nothing special really.
UPDATE: I had the PUT/POST reversed. It reads correctly now. (Thanks to commenter Rob for pointing it out).
There is a bug in the current ADO.NET Data Services that ships with .NET 3.5 SP1 Beta 1. The problem involves saving related data. If the child object requires the relationship to the parent object, the update fails.
For example, if you have a Customer with a list of Orders. The relationship between the Customers and Orders is 1...* (0 or 1...* doesn't cause this bug). If you create a Customer and an Order to be updated with the ADO.NET Data Services client library at the same time, the current code attempts to save both the Customer and Order and then update the link between them separately. Of course if the relationship really is 1...*, then you can't save an Order that doesn't have a customer so the update fails. Unfortunately this can update the Customer and just ignore the error with the Order not saving.
I've known Julie Lerman (or is it Julia these days ;) for a long time now. She's an excellent resource for everything data related. In particular she's been keeping up with the Entity Framework and ADO.NET Data Services (formerly Astoria) updates in .NET 3.5 and VS SP1 Beta that was just released this week. If you are upgrading projects (like I am), she has two excellent blog posts about how to upgrade your projects:
If you havent voted, please feel free to vote for what data access strategy here:
I had interesting conversations with a number of people about different data access/ORM strategies at MIX recently and was trying to understand where people are spending their efforts in consuming data. The conversation was essentially a discussion of who is using what to access data in .NET applications. I had assumed that certain solutions were widely used and others were not but I didn't have a good idea of what the market was really like. To help me with this I am asking you (my readers) to share with me where you are investing time in data access by taking the following poll:
|Vue.js by Example (New Lower Price)|
|Bootstrap 4 by Example (New Lower Price)|
|Intro to Font Awesome 5 (Free Course)|
|Building an API with ASP.NET Core (New Course)|
|Building a Web App with ASP.NET Core, MVC6, EF Core, Bootstrap and Angular (updated for 2.2)|
|Less: Getting Started (New)|
|Using Visual Studio Code for ASP.NET Core Projects|
|Implementing ASP.NET Web API|
|Application Name||WilderBlog||Environment Name||Production|
|Application Ver||v4.0.30319||Runtime Framework||x86|
|App Path||D:\home\site\wwwroot\||Runtime Version||.NET Core 4.6.27317.03|
|Operating System||Microsoft Windows 10.0.14393||Runtime Arch||X86|