In previous posts, I've talked about (and posted) some CodeSmith templates I wrote to generate my stored procedures, data access layer and my initial business layer.  I've now used that approach successfully on several client projects and thought I'd share more of the details.

Before I start, I'd like to talk about my experience with some of the other approaches.  Keep in mind that each approach has its strengths and weaknesses.  I don't consider my approach to be a "silver bullet", but as I said, it has
worked successfully on several projects.  We (architects, developers and code-monkeys) should always try our best to find and use the best tools and techniques to accomplish our goals (or those of our clients and employers).

Some people are big fans of Object Relational Mappers (ORMs), but I have yet to find one that is intuitive enough for me to simply start using.  I don't want a big learning curve, I don't want to have to hack Xml and I don't really want to clutter my projects with a bunch of references.  I want to be productive and I want to be productive
quickly.  The ORMs I've tried had great promise, but even after reading the docs, I still found myself struggling with the simplest of operations.  I've still got Paul Wilson's ORM on my list to review.  Who knows.  His may change my
mind. :-)

Ok, so here's the plan for this series of blog posts:
1. How I "architect" and design an app.
2. The database
2a. Stored procs vs. dynamic SQL
3. The Data Access Layer
4. The Business Logic Layer
5. Gluing it all together

Note: I can't stand using "architect" as a verb, that's why I keep enclosing it in quotes.