by Arra Derderian
5. May 2010 18:33
N-tier design consists of building out stored procedures and functions which are called by a "DBHelper" or database wrapper class which is then called by your application layer consisting of various business objects. This is the model I have always used when building websites and applications and it has always worked out great. I easily instantiate my business objects on my webpages and bind controls to their properties while encapsulating all the application logic inside their classes while also utilizing the DB wrapper class to make updates to these objects. Recently I tried out some of the capabilities of LINQ to SQL on a site we built in an effort to learn the technology. The site consisted of basic objects such as Products, Companies, and Product Lines. I was able to build my database tables and configure all my relationships in SQL Enterprise Manager and then simply drag those tables onto the DBML designer and presto I had my DB wrapper class and application layer built for me. I then created a static "DBMLHelper" class that retrieved and updated the tables using LINQ constructed queries.
All of this seemed great since I did not need to build application objects, associated constructors, public properties, and db methods which takes up much of the time. Also when deploying the project all I needed to do was deploy the tables and not worry about all the stored procedures. It is also great since I can SVN all my code and not worry about having to script out every stored procedure. I could easily get lists of objects and use LINQ to query them for whatever objects I needed and had all property relationships at the tips of my fingers.Lastly, it supported my dynamic environment configuration settings as well which was very nice.
Throughout all this I was wondering what drawbacks there might be. One problem I encountered was circular references. This kept happening because LINQ would create properties of parents on the children objects when I had one to many relationships. I had to spend some time customizing my DBML using the properties window turning the "Create Parent Property on Child" feature off. Also everytime I changed a table I had to rebuild my DBML and it never rebuilt it exactly how I had it. This caused me some frustration when having to modify all my Child property settings each time and I can guarantee in a large scale development environment this could get tedious. Lastly, because I place a good amount of custom code in my application layer and LINQ to SQL generates this all for you I could not modify this dynamic file by hand because it would get overwritten each time I regenerated my DBML. Things like application object caching, custom formatting, and exception checking would have to be moved to the DBML wrapper class. Dealing with sorting was also annoying because you could not dynamically performa a sort based on a parameter where in SQL you can. The last thing I thought might be a problem would be when I have a very complex query that SQL can do very well, writing it in LINQ would not only be hard but it might not write the "best" SQL for the job and thus create a performance problem without you knowing.
In the end I am not sure where I stand on the issue of classic n-tier design vs. LINQ to SQL. There are pros and cons for both. I think mainly for small project involving clearly defined object types it is very helpful and eliminates a lot of repetitive SQL and application code. This is probably where I will mostly use it for now. I also think exploring all of the LINQ syntax and abilities may sway my decision in the future as I have heard other developers rave about LINQ to Objects and LINQ to SQL. I plan on trying to integrate in my upcoming projects and hopefully it can make my life easier without sacrificing the flexibility of an n-tier model. Many times when Microsoft tries to make things more convenient for the developer (Microsoft .NET AJAX Library) we end up sacrificing a lot of felxibilty and gain a lot of overhead (unecessary script files).
Let me know your experiences!
Subscribe