I’m finally getting around to mentioning the cool stuff I saw last Tuesday. Microsoft was kind enough to visit our small town of Green Bay Wisconsin. They showed off some of the cool new development technologies coming up. As always, it was a great learning experience, and a great way to get a quick overview and demo of what they’ve been working on.
WCF
The first thing we saw was WCF, which is the Windows Communication Foundation. I was really impressed, but I thought it was going to be something more revolutionary. Instead, it looked like it was just ASP.NET webservices on steroids. By steroids, I mean security and extensive configurability. Don’t get me wrong, it’s very cool, but I don’t see myself using it anytime soon since it doesn’t really apply to any projects I’m currently working on.
LINQ
Next, we moved on to LINQ, which was what I was most excited about. Basically, it’s a really nice way of moving your database logic into your application code. We saw some neat demos, where the presenter was able to do amazing data reads with a fraction of the code that you would have needed previously.
What I didn’t like about the demos was the fact that they could give the audience the wrong idea. For most projects, I like to keep my data layer separate. Writing SQL code in the UI layer is just asking for problems. What happens when you want to reuse that query? What happens when you want to add caching?
I also starting thinking about how you would actually use it. The examples showed him populating a few fields of some objects. If you had to pass those objects to other methods, they need to know what fields have been populated. In fact, you would normally want them to assume that the object was completely populated. Imagine one method that retrieves a bank account object. It gets the customer information, but not the account balance. That object then gets passed to a method that deposits money into their account. Since the amount is 0 (it wasn’t loaded), it will add the balance to 0, and save it back to the database. You either have to start tracking this, or load everything ahead of time.
I’ve been using NHibernate a lot in my projects lately. Their approach is typically to load all fields in the object. When I start using LINQ, I intend to use it in the same way. LINQ will basically replace NHibernate and let me write a little bit less code, which means less development time, and I’m more likely to get it right the first time.
I love O/R mappers because they can have a dramatic impact on development times. They also perform surprisingly well, assuming you use them appropriately. It’s great to retrieve a set of objects, and have it it write all of the complicated joins for you, and get everything in one operation. This is certainly possible with plain old ADO.NET, but you’re going to spend a lot of time squeezing a marginal amount of performance out of it.
LINQ will be available in .NET 3.5, which should be released within the next 6 months.
Silverlight
The last topic of the day was Silverlight. Silverlight is basically an Adobe Flash replacement. I was excited that I could use managed code to build flash applications, but I’m sadly mistaken. First of all, animations are typically done inside of a product called Expression Blend. It does seem easier to use than the flash editor, but it’s still a whole new paradigm to learn for most developers. It’s typically geared at designers.
It is surprising to most that it was designed to be cross-platform, and there are going to be plug-ins available for OSX and Linux.
For driving the animations, I though that you were able to managed code (C#, VB.NET, etc). The truth is you will be able to use managed code, but not until Silverlight 1.1. Silverlight 1.0 is driven by JavaScript, which is not very appealing at this point.
I’m still struggling with the line that determines where the UI design ends, and the developer work begins. One of the Silverlight samples shows a paint swatch. Clicking on a color brings up one a bunch of those color sheets you get at the store when picking out a paint color. The animations were done in XAML, created with the Expression editor. Should the UI designer be writing those animations? What if the animations are conditional, and require code? What if you’re designer decides to write the code that drives it, but it doesn’t fit in with the code you already have? What if it’s just flat out bad code that you now have to maintain?