core.net

Oh boy! I have a lot of things to blog about, mainly posts on "Atlas [now ASP.NET AJAX Extensions] at last" and "MS Speech Application SDK". My reason for staying away from blogging was that I was buried in a project in Pakistan till December 2006, after I came back from the MVP Open Days in Turkey in September. Anyway, I have just shifted to USA, and will try to blog regularly from now on.

As developers (and architects) come to terms with the changes that would come with LINQ and the ADO.NET Entity Framework, and the impact it would have on business applications, many existing applications developed or ported to C# 2.0 or VB 8.0 from previous version would never be able to exploit its benefits. Architects and developers working on new software applications or application functionality, however, can make the wise choice of using the Web Service Software Factory to generate business entities, and expose them through web services. (more on that coming up in future posts, HOPEFULLY).

Hardly any developer would want to be bogged down with writing business object classes to represent the entity tables in an enterprise application. The alterative for O/R Mapping, in most cases, is to turn to techniques for code generation, that allow generation of business object code for data access; NHibernate being one of the most popular ones.

SubSonic is yet another O/R Mapper or DAL code generator on the horizon, and does not involve using a separate application for code generation. All the developer needs to do to use SubSonic is add a reference to the actionpack.dll file and add some tags to the web.config file, and thats it. Even more amazing is the fact that SubSonic allows developers to swiftly generate web pages for inserting, updating, and deleting records in the table, kind of like the ones used in administration sections of most websites. Check out the SubSonic site to learn more.

Without a doubt, code generation can give development teams a head-start, when it comes to rapidly generating business entities as soon as they have a database design in place. However, a fact that is often overlooked in enterprise applications, when there are literally hundreds of tables the code needs to be generated for, is that business entities seem to loose their original meaning, and instead exist only as code stubs for data access logic pertaining to the tables they were created for. The same thing happens if you use strongly typed datasets to represent business entities.

A good data-access pattern within a good system architecture, would be to have a separate layer between the DAL (mainly stored procs and logic residing on the database), and the business logic layer (which includes business objects). This new layer would comprise the code generated using an O/R Mapper. While developers building a project from scratch, and trying to get it completed in the scheduled time, would very much want to overlook this important aspect, since it would need to done manually without any code generation. I will try to illustrate using an example. A typical "Employee" business entity generated using an O/R Mapper might have methods like Insert() and Update() for saving and updating a record in the Employee. For most development teams trying to meet the dealine, this is good enough. However, a great design would create the same Employee class (in a different namespace) that would have methods like Hire(), Create(), ChangeAddress(), IncrementSalary() etc. calling the same Insert() and Update() methods under the covers. Not only does this make the code far more readable and self-explanatory, but also highly maintainable. The advantage of using this approach becomes even more profound when you are dealing with tables that do not necessarily represent real-life entities, and require methods like Debit(), Credit, TakeBack(), Adjust(), Reconcile() etc.

For now, I would recommend a Webcast that should get you up and running with DAL generation at SubSonic speeds.