.NetTiers: Avoiding Typing Boring Code
Perhaps, like me, you often perform the role of .NET developer and you hate typing boring code. One example of really boring code is all the stuff you have to type in order to make a nice Business Object Layer, so you don't have any ugly database stuff anywhere near your UI (and also so you can take advantage of the shiny new ObjectDataSource Control!). Then you also have to type out all those boring CRUD stored procedures <yawn>. I hate doing that, and have for some years now actively sought to avoid the soul-sucking boredom creating this all-important code entails.
(Of course, this being ORM we are talking about here, I am proposing we take a data-centric approach to our-tier architecture rather than creating a nice OO model and trying to persist it. OO and ORM don't mix IMHO; I think all of the problems of trying to do this are nicely summed-up here.)
One solution I used on a project once is called LLBgen Pro, which you point at your Database, let it generate some metadata to use at run-time, and then just call it's myriad of methods whenever you need a Business Object to CRUD. Pretty good but it doesn't (or at least, it didn't when I used it) use stored procedures - it uses dynamic SQL and I was just uncomfortable with that as a best practice. You also don't get the source code, and it's harder to make adjustments to the way it works.
On another project, I used a framework called the CSLA by Rocky Lhotka. This saved me and my team an enormous amount of time and solved quite a number of Architectural issues I had been grappling with for some number of weeks (I'll write an article about that project some time - it was pretty interesting). Best of all, it introduced me to a fabulous little tool called CodeSmith, which I turned to as some enterprising individual had gone to the effort of writing some templates for CSLA for it. This enabled us to crank out our CSLA Business-Objects just by pointing CodeSmith at our Database Schema! That project was a great success and I instantly became a big CodeSmith fan.
On a more recent project, the need for a nice n-tiered architecture was again to the fore, as was my desire to avoid typing it all out. This is when I first came across ".NetTiers". Unlike the CSLA, which had templates created to support it, this is just templates. There is supporting code, but it is all indespensible best-practice stuff you might (should! IMHO) well have incorporated anyway - like the Enterprise Library, NAnt, NUnit and NDoc. Oh, and it's free! It's still in CTP but I've successfully gone live on a project using it and it's very flexible. Of course if there is anything you don't like you can just change what it generates - it's just a set of templates, after all, and they are themselves just like ASP.NET and simple to change.
Like most templates created for CodeSmith, you just point .NetTiers2 at the SQL database you would like it to generate code for, indicate a few useful variables like the namespace you would like your code created in, and you're away. It will generate all your SQL stored Procs, your business entities, a Web Service layer if you want it, an web-based Admin interface if you want it and even a VS2005 project for each. It does optional handy things like generate enums from tables you indicate, uses partial classes to allow you to add code to your business objects you don’t want to be later overwritten when you re-gen, and has a nifty feature called “Deep Load” where, given a parent object, the generated code will fill in and add to the parent all of it’s children (as defined by relationships in the database). There is a version for 1.1 of the .Net framework too - available here.
There is a doc attached to this forum post that talks about the latest release (2.0, now released) and how to use it. I heartily recommend every developer who hates typing boring CRUD code take a look at this document, as it's just lots of easy-to-consume screenshots and some explanatory words and you will quickly come to understand what it offers - well worth the investment of your time, even if you feel you have no immediate need for such a tool because you're sure to one day.