Today I ignored Windows 8 and focused on sessions pertaining to ASP.NET, a topic with much more immediate impact to my current professional tasks. Tomorrow I hope to devote the day to Windows 8 topics.
ASP.NET 4.5 loves HTML5, CSS3 and JavaScript
ASP.NET does not have a good story to tell about creating rich client applications - the answer is pretty much code it by hand. One thing I was hoping to hear at this conference was an announcement along these lines. I was very excited to see this session and chose it as one of the first I would watch, only to be very disappointed. A general discussion of HTML 5 was followed by the general explanation - "to use this in ASP.NET 4.5, you just go ahead and use it." That's it? Hey Microsoft, you need a much better solution for creating rich client side experiences in ASP.NET than "code it yourself."
Create rich, data-driven Web apps with ASP.NET 4.5 Web Forms
Web Forms? Really? The speaker sounded surprised to see 100 people in the audience for this talk and said that he lost a bet. But web forms are still thriving out there, and the sincerity of his surprise was revealed when he revealed that "Our figures suggest anywhere between 80% and 90% of our customers are still predominantly using Web Forms." Legacy apps, pal, legacy apps!
This session centered on a feature new to Web Forms, Model Binding. Already available in ASP.NET MVC, this arrives in ASP.NET Web Forms as an enhanced method of data binding. It combines data binding and Entity Framework to give manipulating models in Web Forms a very distinct flavor of MVC.
Although it looks like you could take advantage of Model Binding without using Entity Framework, using EF makes it very simple. A quick review of Entity Framework: this is Microsoft's ORM, with many similarities to other ORM's such as nHibernate. One very cool feature is that your implementation can start with a data schema, a data model or coded business entities and EF will automatically generate the other two. It makes strong use of LINQ - queries don't return huge memory block of data, but an IQueryable interface, or pointer to the data. Because of this paradigm the data is only loaded when actually accessed - this is important in the upcoming discussion. If you haven't looked into Entity Framework at all, I suggest you stop reading this drivel and check out some web articles about it - you'll thank me later. (Come to think about it, even if you just stop reading this drivel to watch a ball game you'll probably thank me later...)
At this point the talk commenced a demo that filled the majority of the time. The demo was a simple CRUD application working with a group of entities (database rows). It eventually included a grid display (with filtering), entity creation and entity updation. I'm always wary of these sorts of demos as they gloss over significant issues in real applications, so I started viewing his demo with great skepticism. I remember demos where data sources were dragged onto a page to provide data sets for binding to controls, ignoring the tight coupling of the schema to the UI, the total lack of type safety and no concept of concurrency - very splashy sessions back in the ASP.NET 2.0 days, but completely useless to people writing real world applications.
The first step was to make the model available to the presentation layer. The demo did this by creating a method in the code-behind class that return the model as an IQueryable interface. Recall from above the advantages of IQueryable over large datasets. Putting this in the code behind class may lead some to feel that it is muddying the presentation layer - not to worry, you can easily put this method on any class in a business layer.
The grid control is then added to the markup on the page and tagged with the method that exposes the model. Columns are defined in a manner similar to current binding, either to a particular property or to an evaluation expression. A key difference here is that current binding defines the properties by a string that is resolved via reflection upon execution for late binding. Binding in 4.5 is strongly typed, so the property name is early bound. This identifies any bad property names at compile time, and gives you autocomplete as an added bonus.
Because the binding is linked to an IQueryable interface, the data is not retrieved from the database until it is actually displayed in the grid. He did not show this, but I would guess that means that paging is handled under the covers by the interaction of the grid and model. It also means that giant blocks of memory containing data sets are not passed around.
A couple filters were added to the page and the values passed to the method retrieving the model. In that routine the filters were then applied by simply adding additional where clauses to the IQueryable object. It was actually pretty simple, plus it acted on the model rather than on the database.
An example of where earlier binding didn't give you the control you needed would be XSS attacks. In prior lives, binding put the code directly in the control without giving you a convenient place to HTML encode the output. If your the source was a data set pulled directly from the database you were at risk of XSS attacks. The binding template now allows you to specify to HTML encode the output, solving at least this particular symptom if not the lack of control problem.
I'm not ready to pronounce this suitable for big apps yet, but I'm more encouraged than the old days. The model is a layer between the database and the UI, the UI is bound to the model not the database. I would have liked to have seen how a much more complex model would look in such an app. The update actions were able to identify optimistic concurrency problems. Where things occurred and how they occurred was clear from the code and and the markup, there were no obvious "then an ASP.NET miracle occurs" moments that usually indicate massive amounts of generated C# code and very little flexibility in functionality.
For more on this topic, as well as all the other new features of ASP.NET 4.5, check out www.asp.net/vnext.
Letters! We Get Letters!
The good news about "attending" the conference locally is that it takes alot less time for the mail to reach me on this side of the country. We've already received mail about the Day 1 issue.
EL from MD writes - Good read. Thanks. I watched the keynote online also. What do you think about Javascript? I thought that it was just a language for script kiddies, but it looks like MS is treating it like a first class language for metro apps.
That surprises me as well. I see the benefit of a (basically) interpreted language in a browser for cross-platform purposes, but if you're targetting a specific OS why not just go .NET? Then I started thinking that HTML5/JavaScript on a desktop Metro app might encourage reuse between platforms or between web and desktop, but they are also introducing Windows Libraries for JavaScript, which will lock your script to the Windows framework. Anyone out there want to explain the appeal of writing desktop apps in JavaScript?
Next Issue
The next issue will focus on more of the new stuff and neat whizbangery surrounding Windows 8 and Metro style apps.
Biff
With our newsletter offices shut down, I guess I'm just some guy watching videos at night in my basement.