bwha-wha-what ?!?!?! > THey are - sorry - stupid inflexible DAL's. If you write a DAL template, you get a DAL class...if you write a full set of architecture templates (with biz obj) you get full architecture > * Inheritance (i.e. the ability to work with OBJECTS, not structs). The templates my company uses provide us a with a common (publishable) data structures, full DAL (and sprocs) supporting all table relations and 99% of query needs based on keys, indexes, and metadata, and a full business object layer including complete internal and relational validation. Almost all of our code is generated into "actively generated" base classes and anything custom we place in the derived objects. >* Query subsystem. Sorry, "GetByCompanyId" is about as idiotic as it can get. How about "get me all customers having open invoices" Problem with a system designed to focus on "get me all customers having open invoices" is that the bulk of all data calls are by key or relation...but because those custom queries are sometimes needed our templates generate our query sprocs with the ability to accept additional query arguments... > The problem is two fold: > * With Codesmith you basically geenerated the code at compile time. This sucks, as this code is not extensible ad runtime. The EntityBroker is compiling the final schema when you start the program, allowing things like dynamic extensions of the mapped classes. I consider "generated at compile time" an advantage...runtime O/R mapping = reflection = sloooowwww. I have yet to find an O/R mapper that can perform anywhere near as well as pure clean tightly compiled code. Code generation gives me the development advantage of not having to code mundane tasks with the performance of strongly typed tightly compiled code. No contest IMHO. > * Codesmith focuses on the class. THis is nice, but way not enough. You have to focus on the classes you map - in context of all other classes. When using a database schema as input, much of the notion of context is contained within the data relations and table relations. If that does not provide enough contextual or business definition you can always use an XML schema to drive your templates and therefore *completely* define your object space before gen'ing. And as you define new business rules or relations you can modify your xml and your templates to understand the new business concepts. You own the schema so it can be as advanced or as simple as you'd like. We tried (unfortunately) a couple runtime O/R mappers on a project for one of our larger clients....HUGE mistake. Performance was shameful and scalability was out the window. We have since engineered a full set of architecture templates that generate 90% of all the code that we produce. Now, our time-to-market is of course way faster, and our application's performance is amazingly good. As we improve our architecture, we improve our templates, and instantly those changes are reflected in all of our objects (well, ok, not instantly, it takes 2 maybe 3 seconds to completely regenerate everything). We've been able to make our object model so easy to use as developers that new employees are up to speed and coding within a day. In fact I'm not sure our junior developers are even aware of the data model or how the business objects get and persist their data...they just do. Company company = new Company(companyId); and company.Save(); are pretty damn simple...no hand coding for any of it. Also, unless I missed something when using them, runtime O/R mappers also = dynamic sql. shame shame shame. If I ever caught one of our developers using dynamic sql on a performance critical (heck on any) project I would puke first and slap them across the back of the head. Any halfway respectable sql architect will absolutely demand stored procedures be used for both performance and security.