In an earlier post this week I wrote about implementing the Model-View-ViewModel pattern in the YouCard application. In this post I’m going to build on that and implement Inversion of Control Containers and the Dependency Injection pattern. Lots have been written about dependency injection, so the focus of this post will be on using dependency injection in a Silverlight context, and specifically how to implement it using the Ninject framework. For an excellent introduction to the pattern I strongly recommend Fowlers essay on the topic.

When getting into dependency injection you might get intimidated by the number of frameworks available to help you implement the pattern. It might give you the impression that dependency injection is something big and complicated, which is going to have a huge impact on how you build your software. The later might be true, but not necessary because of the framework but rather by the flexibility gained by introducing this pattern. In its simplest form dependency injection is about how you supply external dependencies to your application classes. In the previous blog post I refactored the Twitter and Flickr integration into external classes that complies with an interface. Depending on if the code was executed inside Blend or the browser I either use the real implementation, or a mock implementation providing some dummy data at design time.

The problem with the above code is the coupling between the YouCardData class and the four classes implementing the IMicroBlog and IPhotoService interfaces. This high level of coupling between the view-model (YouCardData) and its external dependencies (Twitter and Flickr) makes the code less flexible. Coding against interfaces enables me to implement other services, such as a Picasa photo service, or a Tumblr micro blog service. The problem is how I get the YouCardData class to use these alternative implementations. The code is also hard to unit test as I can’t provide a mock implementation of the external services. We could refactor our code to take the external dependencies as constructor parameters like this:

By doing this we allow the consumer of the YouCardData class to inject the external dependencies through the constructor. And in essence this is constructor based dependency injection, by hand. The above change gives us greater flexibility to provide alternative implementations of the services, either for testing purposes, or to provide new functionality. But there is still a problem with the code. If you want to create an instance of the class from XAML, for instance when setting the data context, a default parameter less constructor will be used. You could solve this limitation by adding an additional constructor like this:

 

This would solve the XAML problem, as any instance crated declaratively would use the Twitter and Flickr implementation, but for testing purposes we could provide our own mock implementation. But the solution still isn’t perfect. In the first constructor we had code to check if the class was consumed inside Blend or not. Depending on this we used different implementations of the external services. We could have kept this constructor, but instead we’re going to use an Inversion of Control container to help us build our objects.

Ninject

Lately I’ve been doing some research on UI frameworks and patterns, and many of these use some sort of dependency injection framework. The Prism-AG framework, a Silverlight port of the Composite WPF framework, uses a small dependency injection framework called DLLite. Another dependency injection ported to Silverlight is Unity, another framework from the Microsoft patterns and practices group. But my personal favorite so far is Ninject, the ninja of dependency injection. This framework caught my attention after listening to Nate Kohari in episode 5 and 6 of the AltDotNet podcast. Ninject describes itself the following way:

Ninject is a lightning-fast, ultra-lightweight dependency injector for .NET applications. It helps you split your application into a collection of loosely-coupled, highly-cohesive pieces, and then glue them back together in a flexible manner. By using Ninject to support your software's architecture, your code will become easier to write, reuse, test, and modify.

The footprint of the compiled framework is only 110KB, and you only need a single reference to Ninject.Core.dll too getting what you need in most scenarios. Strength of Ninject is the focus of configuration through code instead of XML. Most other IoC containers have a strong emphasis on XML based configuration of object dependencies. This has its advantages if your deployment environment varies a lot between installations, but in many cases this adds additional configuration pain.

1. Your configuration can get more complex and verbose since you often have to write out fully qualified assembly names for each type.
2. Its easer to break the application through simple typing mistakes.
3. If the rules describing how to write your application together gets complex this might be hard to express through XML.

In comparison, Ninject uses a fluent interface, or sometimes referred to as "embedded domain-specific language". This lets you take advantage of the programming language to build up the wiring of your application. You can express complex rules of how the wiring should happen, and there is nothing stopping you from writing code that reads a configuration file if some of the wiring depends on user configuration.

"… There are cases where it’s easier to use program code to do the assembly. One case is where you have a simple application that’s not got a lot of deployment variation. In this case a bit of code can be clearer than separate XML file.

A contrasting case is where the assembly is quite complex, involving conditional steps. Once you start getting close to programming language then XML starts breaking down and it’s better to use a real language that has all the syntax to write a clear program.

…My advice here is to always provide a way to do all configurations easily with a programmatic interface, and then treat separate configuration file as an optional feature. – Martin Fowler"

Another cool aspect of Ninject is that it support Silverlight “out of the box”, and is not a port or a trimmed down version of a larger framework. Ninject was small to begin with.

Dependency Injection with Ninject

Adding Ninject support is fairly straight forward. The first thing we need to do is add is marking all constructors that take the dependencies, and mark it with a simple attribute.

We also want to inject a persistence service into the main page view-model, the one controlling all the cards on screen. The persistence service is used to store all the users added, so that we don’t have to add them again when we come back to the application.

If we use the Twitter service implementation we also want to inject a proxy URL. This is because Twitter doesn’t allow cross-domain callers and we need to proxy the request through our own server.

The next thing we need to do is to wire the view-models to the services they need. In many IoC containers this is done through XML configuration, but in Ninject this is done through code and a fluent interfaces. Ninject uses a concept of modules to wire things together. One kernel (the container) can host multiple modules. For the YouCard application we need only one module.

The benefit of fluent interfaces is increased readability of the code, so I’m not going to spend too much time describing the class line by line. The class derives from StandardModule, and overrides the Load method. In the Load method we set up the binding between the services and the concrete types. If you read the binding as “English”, from left to right, the binding rules should be fairly straight forward. Also worth notice is how I take advantage of configuration through code when I decide which implementation to use when the code is running inside Blend. I add a condition saying that the Twitter service should be used when executing inside the browser, while the mock service should be used from Blend.

To use the module I simply have to create a Ninject Kernel and pass it the module.

 

Notice how I don’t have to worry about constructing the YouCardData object. The kernel takes care of instantiating the object, and injects any dependency based on the bindings configured in the YouCardModule.

Data binding to objects built by Ninject

Now that we have configured our Ninject kernel the next challenge is getting our view-model objects out of the kernel and into the views, without breaking the design time experience in Blend. Setting the data context through code would be fairly simple. We could create the kernel in the application class, and then get it doing something like this.

 

That would enable us to have one kernel for the application (something you typically do). But it still wouldn’t solve how to set the data context of a user control to view-model built by Ninject, using declarative XAML code. This troubled me for a few days, and after thinking it through, trying some different approaches, and talking discussing it with Nate Kohari the solution turned out to be Service Locators. This is a different pattern used to implement Inversion of Control, and often you decide to use either service locators or dependency injection. I recommend reading the section on service locators vs. dependency injection in Fowlers essay for a good description of the pattern.

The short version of the pattern is that a service locator is a registry holding references to all the services used by your application. A class, such as the view-models in YouCard, can ask the service locator to give them an implementation of IPhotoService or ITwitterService. The big difference between service locators and dependency injection is that with SL your classes asks for an implementation, but with DI they are given an implementation (pull vs. push). Nate has blogged about how Ninject plays nicely with service locators.

"I don’t think that service locators and dependency injection are mutually exclusive; in fact, I’ve found that it can actually be very effective when used in conjunction with a dependency injection framework like Ninject. – Nate Kohari"

The service locator I’ve created for YouCard is fairly straight forward.

In many cases you implement the service locator as a static class. That was not an option, as Silverlight 2 doesn’t support data binding to static classes. The way I solved this was to make a static constructor, and a private, static kernel field. The static constructor is the first thing executed in the class, before any standard constructors. The static constructor checks if we have a kernel and if not it instantiates one using module containing our binding configuration. By making the kernel field static we can ensure that we have only one instance of it in our application. The class has two instance properties that surface our view-models from the kernel, as well as a generic instance method to get any object from the container.

Before introducing dependency injection we bound our views to the view-model declaratively like this:

After introducing a service locator we need to change this around a little. The first thing we do is to instantiate the service locator as an application level resource:

Then for each of the views we need to change how they get their data context.

Each of the views gets their view-model by data binding to properties on the service locator. The coolest thing about this approach is that we still get full Blend design time support with sample data provided through the mock services.

Conclusion

Introducing dependency injection in Silverlight isn’t any harder than in other .NET applications. The strong focus on keeping the framework light weight and extremely fast makes Ninject a perfect fit for Silverlight. However, one could argue that for a simple example like this Ninject isn’t really necessary. I could hand-write the dependency injection code inside my service locator, and eliminate the Ninject dependency, and still get the flexibility of dependency injection. On the other hand, Ninject is only 110KB (before it’s zipped into the XAP file), and isn’t going to add a lot of download weight to your application. 100KB is less than half the size of the images used as illustrations in this blog post...

By using dependency injection you keep your code more flexible and testable, something that is just as important for Silverlight applications, perhaps even more, are UI requirements are likely to change a lot as you discover the power of Silverlight. I strongly believe in providing designers with a best possible experience inside Blend, and there is no reason for dependency injection to change that.

After the iPhone 3G release two weeks ago the web has been flooded with articles praising this eighth wonder of the world. I’ve been using the first gen iPhone since December, and have been really happy with it. I guess my biggest issue with the phone has been the crappy camera (which sadly isn’t improved in the second gen iPhone). Since I’m running a jailbreaked phone I haven’t been able to update to 2.0, until now.

On Sunday the code wizards in the “iPhone dev-team” released the much awaited Pwnage 2.0 tool. Currently it’s only available on the Mac, but there are tutorial describing how to use a prebuilt IPSW file and jailbreak your iPhone 2.0 from a PC. I used my girlfriends Mac to upgrade to 2.0, unlock and jailbreak my phone. The only issue I had was a popup in the Pwnage tool asking if “I’m a legit iPhone user”… Well, I didn’t steal the phone, so I guess yes..? Well, turns out this question determines if your phone gets unlocked and jailbreaked, or just jailbreaked. Had to run the tool twice, and answer NO to this question to get it to work.

One of the things I’ve been missing the most after changing job and mobile last year is the Exchange support in Windows Mobile. Thankfully this is one of the big things on the iPhone 2.0. One of the things I did some time back was to consolidate all my e-mail accounts through Google Apps for your domain, and Google have been hosting the mail for follesoe.no for over a year now. With added IMAP support Gmail works great from any client application, as well as on the iPhone. I haven’t had a good way to manage contacts and calendars, but I want to use Google Apps as the master, and then sync it with both my iPhone and my PC. Unfortunately Google does not support the Exchange ActiveSync protocol natively, but there are third party services that will gateway your Google Calendar and Contacts and provide Exchange access to it. One of those services is the easy to use, free service from NuevaSync. I came across this service in a blog post titled “Using Google as a *free* Mobile Me Alternative with NuevaSync”.

After configuring NuevaSync I needed to find a way to get my contacts from Outlook 2007 and into Gmail Contact. The optimal solution would be to connect directly from Outlook 2007 to NuevaSync. I was a little bit surprised to learn that you can’t force Outlook 2007 to use the Exchange ActiveSync protocol used by mobile devices. Since NuevaSync doesn’t support the full RPC protocol used by Exchange this wasn’t an option. So my second alternative is to find a way to sync my local computer with Google Calendar and Google Contacts.

People have had mixed experiences with Google Contacts. Gmail can clutter your address book by automatically adding people you communicate with. This is now an optional feature, and you can disable automatic adding of contacts. After disabling this feature and deleting all existing online contacts I was ready to do the syncing. Problem is that I couldn’t find any good tools to do this. There is a free tool from Google that will sync your calendar, but it doesn’t support contacts. OggSync is another alternative. But the free/trail version doesn’t support contacts either, and I’m not paying until I’m sure it works nicely.

The solution to my problem turned out to be open source software. I’ve been a big fan of Firefox for a long time, and figured this might be a good time to check out Thunderbird. Setting up Thunderbird with Google IMAP is a breeze, and well documented by Google. Thunderbird also supports contact imports from Outlook 2007, so I didn’t have any problems getting my contacts into Thunderbird. To synchronize contacts between Google Contacts and Thunderbird I used the Zindus add-on. Thunderbird doesn’t come with a calendar out of the box, but with the official Mozilla Lightning extension you get both calendar and tasks support in Thunderbird. I also had to install a “Provider for Google Calendar” add-on to get Lightning to sync with Google Calendar. My current setup now looks something like this:

I have to agree that it might look a little bit messy, but it works. And it’s free! It’s just something really pleasing of being able to add a appointment on the iPhone, and seconds later see it show up both in my online Google Calendar, and in Thunderbird. Or to edit a contact in Thunderbird, and moments later have it updated both in Gmail and on my phone. I’m quite happy with the current setup. And the important part is that the “master store” is kept on my Google Apps for your domain account.

And for the other new stuff in 2.0: the app store is just AMAZING! So many great apps, really nicely integrated both on the phone and in iTunes. So far my absolute favorite app is the iTunes remote control application. I’ve used Pocket PC based remote control software, but this one is just awesome! Now the only thing missing is an equally good Vista Media Center remote control, and the iPhone just became the coolest media remote ever.

If you haven't upgraded yet, go do it!

The Model-View-Control (MVC) pattern is more popular than ever. Microsoft has now jumped the bandwagon with its ASP.NET MVC framework. Other popular frameworks like Ruby on Rails, Django (Python) and the Spring MVC Framework (Java) all implement this popular pattern. The MVC pattern fits nicely into the request-response based nature of the web. As a request comes in, the controller makes a decision on what needs to be done, talks to the model and hands of the rendering responsibility to a view engine.

Silverlight on the other hand, even if it is running inside the, has more in common with rich client application frameworks like Windows Presentation Foundation than traditional web applications. This requires different thinking when it comes to architecting the application. In this post I’m going to talk about the View-Model-ViewModel (MVVM) pattern or as Fowler call it; the Presentation Model. As an example I’m going to re-factor my YouCard application to use this pattern.

Jon Gossman and Dan Crevier have blogged about the MVVM pattern in a WPF context, and recently Nikhil Kothari wrote an excellent post titled "ViewModel Pattern in Silverlight using Behaviors". Martin Fowler has also written about this pattern, but under a different name; the Presentation Model. What makes ViewModel so interesting for Silverlight and WPF applications is that it lets you take full advantage of the strong data binding support in Silverlight and WPF. One of the key concepts of the MVVM-pattern is to define specialized models that are tailored for a specific view (user interface). The view-model may contain special fields like IsDiscountingEnabled, or PageTitle that may be based on one or more fields form your under laying domain model. Your IsDiscountEnabled field might be based on whether or not the logged on user belongs to a specific group that have the permission to give discounts, but the actual view does not know or care about this. The view only cares about the IsDiscountEnabled field of the view-model, and is not coupled to the domain model. The view and the view-model are highly synchronized, while synchronization between the view model and the domain model only happen at certain points, like when the user hits the Apply or Save button. How you implement this synchronization between your view and your view model depends on the technology you use, but even Fowler suggests that this can be done through data binding:

Probably the most annoying part of Presentation Model is the synchronization between Presentation Model and view. It's simple code to write, but I always like to minimize this kind of boring repetitive code. Ideally some kind of framework could handle this, which I'm hoping will happen someday with technologies like .NET's data binding. – Martin Fowler

The synchronization code Fowler is talking about is the code where you move values from the name-textbox to the name-property on your Person object. I’m sure we’ve all written that code and can agree that it’s both boring and repetitive! Thankfully data binding has improved a lot since the .NET 1.1 and Windows Forms days, and in WPF and Silverlight data binding is a natural choice for implementing this synchronization.

The application I’m going to use as an example of this pattern is my YouCard application from REMIX Australia. At REMIX I talked about Silverlight 2 for designers. The focus of the talk was about using Blend 2.5 to build and design applications. The core of the application is a YouCard user control, which is data bound to a YouCardData class. This class contains functionality to retrieve data from Twitter and Flickr, and acts both as the model and the view-model for the application. It contains View-specific fields like Tweet, Name and Bio, which all are extracted from the Twitter-feed downloaded from Twitter using HTTP requests. The YouCardData class starts a timer that downloads new data from the Twitter or Flickr at given intervals. To follow good programming principles like single responsibility, I’m going to split the Twitter and Flickr functionality out to external classes. These classes will be our Model. The responsibility of these classes will be to download and parse XML into objects. The YouCardData class will become our ViewModel and will be responsible for using the Twitter and Flickr service in a way that makes sense for the View, and surface up any fields needed by the UI. Since the original design of the YouCardData class was built to highlight the strong support for data binding- and design time support in Blend 2.5, we have a good starting point for this refactoring job. The following diagram shows the current design (left) and the desired design after some refactoring:

The first thing that needs to be done is to define some interfaces for the external services. Instead of defining an ITwitter or an IFlickr interface I have decided to use more generic names like IMicroBlog and IPhotoService. That makes more sense if we ever want to support FriendFeed, Picasa or perhaps Windows Live Photo Gallery. I am going to refactor the existing code into two concrete implementations of each interface, one for the real online service, and one mock implementation with dummy data. As I mentioned earlier this application was written as a demo for the creative track at REMIX, and to provide a good design-time experience in Blend we need to generate dummy data when the code is being consumed by the designer. If you are going to benefit from the designer-developer workflow XAML enables, you need to start thinking about how your code behaves inside the design tool. In the current implementation dummy data is provided in the YouCardData class through an if-statement in the constructor checking if we’re running inside Blend or not. If we’re running inside Blend the YouCardData class will use a mock implementation of the Twitter and Flickr services. If it’s running inside the browser it will start a timer and begin to download data from Twitter and Flickr using the real implementations. The important part of the YouCardData constructor now looks something like this:

 

You might notice that this code screams for some dependency injection, and that is exactly what I’m going to cover in my next blog post. We check the type of the current application object. Blend provides its own application object, while actually running the application gives us our own application object.

The next piece of the application that needs some refactoring is the main user interface. By that I mean everything around the cards. Today the application contains one text box where you enter in a Twitter-username, and an add-button to add a new card. In the click-event handler we instantiate a new YouCard user control and add it to a stack panel. We also hook up an event handler listening for a close-event fired by the YouCard control. If the event fires we remove it from the stack panel. This approach is bad for a number of reasons. The main problem is that we are building too much behavior and logic into the view (the code behind of the XAML page). For instance the designer doesn’t have the freedom to change from a stack panel to a flow panel without changing the code. It’s also hard to unit test the code since much of the application logic is bound to specific UI-controls and UI-events.

To solve this problem we create a new view-model that contains an observable collection of YouCardData objects called Users. This collection is bound to an items presenter control, which uses the YouCard user control as its data template.

With both pieces of UI bound to view-models we have now control over how we display data. But this is just half the story of an application. We also need a way to interact with the view-model as the user adds or removes cards.

In the YouCard application there are two points of interaction that affects the view-models, the textbox and button to add a new user, and the red button to remove a card from the list. The user can type in a username and hit enter, or click the add button to add a new item to the Users collection. The add button should only be enabled if the user name is valid. When the user clicks the close button of a card we need to remove the item from the collection in the view-model. In this case it involves communicating from one view to the view-model of a different view. The YouCard user control needs to tell the view-model for the main UI to remove itself from the list.

The most obvious solution could be to add a click event listener on the add button, and call methods on the view-model to add a new users. We could listen to the text changed event of the textbox to validate the input and enable/disable the textbox based on the text. We could also add an event to the YouCard control that gets fired when the user clicks the red button. The main view could listen to this event, and remove the corresponding card from its view-model. The problem with this solution is again that we will be baking logic and behavior into the views, which should be owned by the designer. It also makes it harder to unit test things like the validation rules, and that any users added or removed is persisted to the local machine using isolated storage (the application stores the list of cards you have added).

To solve the interaction between the view and view-model we’re going to apply the command pattern. The command pattern enables us to encapsulate an action into a command object. The command object normally contains an execute method, a name and description, and some information about whether or not the command is enabled. A single command can be attached to multiple UI elements. You might want to invoke the open-file-command from a button, a keyboard shortcut and a menu item. WPF have built-in support for Commands, but this is not included in Silverlight 2.

Nikhil introduces some really cool ideas on how to enable command-like functionality through Silverlight behaviors. This is the same concept used to extend ASP.NET controls with AJAX behaviors. In his first ViewModel post Nikhil uses the following syntax to invoke commands from XAML:

Using an attached property he adds a behavior to the button which invokes the Search-method on the view-model, passing in the text property of the search textbox as the parameter. In a follow-up post Nikhil shows how he managed to get the syntax even more compact using the Dynamic Language Runtime:

The cool thing about this approach is that you can write any dynamic language expression into the attached click event. This can include method invocations and getting parameters from other elements on the page. This gives you amazing flexibility to link your view to your view-model. The problem with this approach is that you get a dependency to the dynamic language runtime, which will affect the size of your Silverlight application. But more importantly for me it breaks design time support in Blend 2.5, so we need to find an alternative approach.

I decided to use a more classic command pattern implementation found in the "Silverlight Extensions" project on CodePlex. The project contains controls, helper classes, extension methods and more. Since we’re only interested in the command pattern implementation I decided to move those classes into the YouCard project. The XAML for our textbox and button now looks like this:

The textbox is bound to a Username-property on the view-model. Both controls invoke the AddCard-command, using the username of the view-model as the command parameter.

The commands are defined like this:

The static Commands-class holds a reference to all the commands available in the application. When instantiating a new Command-object it gets added to a static dictionary on the Command-object, caching any command object created by the application. When using the CommandService-attribute from XAML, the CommandService class will link the UI-element with the correct command using a CommandSubscription class. When the user clicks the Add User-button, or hit enter in the textbox, the CommandSubscription-class will listen for the correct UI-event and trigger the Executed-event for the correct Command-object. Any class that wants to take action when this command executes simply listens to the Executed-event of the Command object. In our case we want to handle adding or removing cards in the view-model class:

Also worth mentioning is the enabling/disabling of the Add User-button. This is done through data binding the IsEnabled-property of the button to an IsAddEnabled-property of the view-model. The IsAddEnabled-property looks like this:

The textbox is bound to the Username-property, which will trigger the PropertyChanged-event for the IsAddEnabled-property. In the getter of the property we apply the validation rules that decide whether or not the button should be enabled.

Hopefully this post gives you another example of how the Model-View-ViewModel can help you keep as much code as possible out of your user interface. The strong data binding support in WPF and Silverlight makes this pattern particularly interesting, as you don’t have to worry about synchronizing your view and your view-model through hand written code. Using commands you can separate the actions of your application from the concrete UI-element invoking it. This gives your designers the freedom to choose which UI elements to use to invoke different actions in your application. Best of all, we’ve been able to do all this without breaking design-time support in Blend. In my next post we’ll continue on improving the YouCard application making it more testable by introducing dependency injection.

Back in June 2006 Ted Neward wrote an excellent article about ORM titled "The Vietnam of Computer Science". Two years later we conclude that we’re still stuck in Nam, and it’s only getting hotter…

nHibernate is now maturing and a beta of their second major release (2.0) was just released. After the failures of Object Spaces and WinFS it looks like Microsoft is stepping up their data programmability efforts with two ORM offerings, LINQ to SQL (part of .NET 3.5) and ADO.NET Entity Framework (releasing in .NET 3.5 SP1). Some developers are fearing (or hoping?) that LINQ to SQL might be the next casualty of war, as there really hasn’t been a lot of improvements or announcements made around LINQ to SQL after its initial release, as expressed in the post "Is the ADO.NET team abandoning LINQ to SQL".

Things got really hot for the ADO.NET Entity Framework team last week, as a "vote of no confidence" was put out. So far it’s signed by 392 developers. Tim Malalieu, program manager on the EF team, responded with a detailed post addressing the concerns rose in the "vote of no confidence", and it’s good to see Microsoft responding to the concerns of the developer community. Microsoft has also put together a council including Eric Evans, Martin Fowler, Paul Hruby, Jimmy Nilsson, and fellow Regional Director Stephen Forte.

Stephen did a great post on his take on the whole ORM debate this weekend, and I figured commenting on it would be a good way of getting "back into blogging" after being quiet for almost three weeks. I mostly agree with what Stephen is saying, and one of the points he makes is about embracing the impedance mismatch rather than trying to ignore it:

So ORMs are trying to solve the issue of data access in a way that C# and VB developers can understand: objects, procedural, etc.  That is why they are doomed to fail. The further you abstract the developer from thinking in a set-based way and have them write in a procedural way and have the computer (ORM) convert it to a set-based way, the worse we will be off over time.

What I am saying (and have been saying for a long time) is that we should accept, no, embrace the impedance mismatch!  While others are saying we should eradicate it, I say embrace it.

One of the things I love about C# 3.0 and LINQ (not LINQ to SQL) is how it gives you a nice way to work in memory data in procedural code. I’ve seen heaps of examples of bad code with several levels of nested for-each loops “mimicking” set based operations. In many cases these big chunks of codes can be simplified to one simple easy to read LINQ expression. But, then again perhaps the problem could have been solved in the database in the first place..?

The ironic thing I’m now seeing is developers who are lazy and don't want to learn SQL using tools that will produce SQL for them. The SQL is bad, and now those same anti-SQL lazy developers are struggling to read pages of generated and near-unreadable SQL trying to solve performance problems. They’re dealing with SQL that’s more verbose and orders of magnitude harder to understand than what was needed in the first place!

This brings me nicely to the reason for my lack of blogging the last three weeks. I’ve been too busy doing database integration and reporting work for a medium sized organization here in Melbourne. The problem I was faced with was establishing a platform for data integration between line-of-business applications to do management reporting. The organization had a basic reporting solution today consisting of a set of VB- and Python scripts being executed by scheduled tasks to pull the data into a report database. The actual reports where generated by an ASP.NET 1.0 application that populates data grids. As you can imagine this is no ideal solution, and is both hard to maintain and extend, and really doesn’t solve the business need of the customer. When the exciting solution didn’t give the reports they needed they had to do manual Excel reports.

The developer in me who loves shiny new framework might see this as an opportunity to migrate the exciting solution to something sassier, say ASP.NET MVC + ADO.NET EF, and perhaps a dash of Silverlight to show some great KPI's. Thankfully I keep “cool” and did the reasonable thing (the "right tool for the job"-cliché): SQL Server Integration Services and SQL Server Reporting Services. I solved the problem by building the SSIS packages based on the exciting scripts, and complimented them with additional imports where needed to meet new requirements. During the report authoring (something I did together with one of their business people who knew what reports they need) I discovered how “rusty” my SQL skills had become. It took a couple of days to "loosen up" and be completely up to speed with writing joins, groupings, aggregators and more to get the reports they wanted. I think this is the case for more and more developers these days.

The database engines are becoming more and more powerful, yet I suspect the average developer to take less and less advantage of this power. By writing "dumb plumbing" code to populate .NET objects we forget the power of the database, and think everything now can be solved by putting a ORM on-top of the database.

That being said I do think the ORM has its place in application architecture, but as any tool you need to learn how to use it right, and know what problem it can solve. Personally I love using ORM for my simple CRUD operations, and whenever needing you can always drop down to hand written SQL. I remember when I did my first ORM project on an early version of LLBLGen back on .NET 1.1. We didn’t have partial classes, so any modification made to the auto generated code had to be written between special region comments that didn’t get overwritten when doing a regeneration of the code… We’ve come a long way since then.

And for the project I’ve been working on: We delivered today, on time and above expectations. The customer already had SQL Server installed (and SSIS and Reporting Services, perhaps without knowing), so deployment was a breeze. The new solution is easier to maintain and extend by the customers IT organization, and offers a unified way to do reporting and data integration. And as for sexy Silverlight 2 KPI gauges we didn’t get time to do it this time. By using Reporting Services to export to XML I’m sure we could do something cool within this framework. Well that’s a whole different blog post...