I know Kathleen Dollard's book on code generation uses CSLA as the target context. It's also my understanding that she takes the approach that applications should be designed and generated from a business functionality standpoint rather than interpreting or mapping tables into objects like all the rest of them seem to do.
I am an avid supporter of this concept. I also am strongly considering implementing code generation in the major application project about to launch.
So, I'm planning to order her book. I wondered if anyone here has had experience with the book and her generator and could give feedback.
Don't have her book, but I listened in to a presentation she did about code generation. She's a very sharp individual with a wealth of practical knowledge to share on the topic.
I would expect her book to be equally useful. She did mention in her talk that she wanted to rewrite on of her chapters based upon new insights, so you might want to send her an email to see if she'll send you an electronic copy of the relevant insights. www.gendotnet.com
She also has a free code generation framework you can download. Some very nice features to it.
QJohnson, Yes I would agree entirely - a good book that tackles the difficult issues facing 'code genners' and yes - a tough read too.
Dan, You may be a little challenged by Kathleen Dollard's take on generating from objects rather than from the database. She takes the pragmatic view that databases tend to exist already and contain a wealth of meta data. She chooses to infer much of her object structures and relationships from the database, only describing where the object model differs from the database. This doesn't preclude the use of a more purist approach, but it does mean that the tools used in the book are more suited to code gen where the database exists already. The concepts discussed in the book remain valid.
Very good book. Recommend it but ignore the ORM section. Don't even try to read it. She has said multiple times that it is awkward and not really worth the effort. But it has been a year since I have read it and new editions may be better.
I don't think the primary value of the book is any particular method but instead the concepts that she uses. One of the main concepts being that it is the Metadata that should drive code generation and that there are numerous sources for this metadata. Database schemas, object interfaces, UML diagrams, hand written files etc. In the end, though, all these sources are probably insufficient for code generation and none match up well with one another. Therefore you should create your own schema then transform the other sources to match yours.
I have built my own based on her ideas and suggestions and am very happy with the results.
>> In the end, though, all these sources are probably insufficient for code generation and none match up well with one another. Therefore you should create your own schema then transform the other sources to match yours. I have built my own based on her ideas and suggestions and am very happy with the results. <<
Brian Criswell:
My main gripes came from the following:
- ...
- Metadata still comes from a database by default
- ...
- Parent-child relationships cannot be inferred from the database without adding some additional metadata somewhere
...I personally found CodeSmith to be much easier to work with than XSLT, ...
Metadata has got to come from somewhere! Database definitions are a "poor man's meta-data repository". If that's all you have, it's better than nothing.
If you've got a meta-data repository tool that contains the extra information, and it can act as the datasource for generating your database definitions as well as your class definitions, go for it.
Parent-child relationships can be inferred somewhat more easily if you are consistent in your naming or if you use natural keys instead of computer-generated id columns for the pk.
If part of my PK is a FK to your PK, then I'm much more closely related to you than if I just have an FK column sitting around outside my PK. Natural keys are "out of style" nowadays, so that's a less useful technique than it used to be.
Naming conventions can also be used to deduce the difference between a parent-child relationship and a simple "I use one of them" relationship. Consider Customer and Invoice Header, or Invoice Header and Invoice Line Item. If we use appropriate naming conventions, we can deduce that Invoice Header is a parent of Invoice Line Item, whereas Customer is merely used by Invoice Header. Invoice Type is not a parent of Invoice Header, because Invoice Type contains a "meta-data identifer word" (Type) in its name whereas Invoice Header does not. Tables with words like type, category or group usually refer to application meta-data (reference code) tables whereas tables without those words are more likely to contain "real" user-data. It's a fairly rare case where we would want to change meta-data and user data in the same program. Those are jobs for people with entirely different skill sets and responsibilities ("system architect" vs. "data entry clerk"). Invoice Type and Invoice SubType would have a parent-child relationship because they are both meta-data tables.
Hope that gives folks some ideas. In the past, I've found that a parent-child true/false tag added to the relationship meta-data is a really good match with the above naming convention/key deductions. The tags are added only to change the default deduced behavior. That way, you don't have to add lots of tags where it's obvious what you want it to do, you only have to do data entry to record the exceptions.
As for working with XSLT, other than for simple stuff, I think I would rather go to the dentist every day to get my teeth drilled. For simple stuff it's pretty cool, but for complex stuff it's just plain unpleasant for me to work with.
Copyright (c) Marimer LLC