It's called FBOA - Foundation Business Object Accelerator - you're able to leverage it if you co-develop with Magenic if I understand correctly. (You can find it on Magenic's site - the mention of it that is)
I do wonder if it actually utilizes one of the code gen options out there.
Me? I don't code gen, myself. Not yet anyways.
(Call me crazy but I don't really know how much I'd benefit - the stuff that's easily replicatable via code generators takes very little time to type and snippets kick butt anyways. Though I can see how something for the DAL could be definitely useful)
I highly recommend using snippets for anyone not already doing so.
Here is an article about creating your own snippets:
http://aspnet.4guysfromrolla.com/articles/122105-1.aspx#postadlink
And Rocky has some in the Csla code - csla20cs\Snippets
Yes, Magenic has a code generator called FBOG. Actually two of them, neither based on a custom generation engine. The first one was for CSLA 1.x and uses the code DOM, the second is for 2.0 and uses straight text output to escape the limitations of the code DOM.
These generators are built with the intent of augmenting Magenic's consultants as they work on projects, and the generator stays behind with the client when our consultants leave. But my point is that they aren't designed for "casual use" like CodeSmith; meaning no docs, a UI that lacks polish, etc. The tools aren't designed to compete with other code-generators, but rather to allow Magenic to compete with lower-cost consulting firms.
Which is a really long-winded way of heading off the next question, which is whether I can make FBOG available. I can't. Magenic owns it, not me, and they provide it as part of their consulting services only.
What I've been working on, off and on, is trying to come up with a new language for describing objects. Perhaps I'm on a fool's errand, but I look at the amount of code required to write an object, even with CSLA, and I think it is ridiculous. If you go through your code and identify only the lines of code that perform actual business functions - that have actual business value - you'll find that it is perhaps 4%. The rest of the lines of code are mandated by C# or VB or ADO.NET or Windows Forms or Web Forms or whatever. All "plumbing", and none of it valuable to the business need.
How does this tie into code-gen? A compiler is merely a fancy code generator. If I can come up with a more concise language to describe business objects (at least CSLA business objects), then I can code-gen CIL directly by creating a compiler for my language.
Thus far though, I have not been happy with any results ![Sad [:(]](/emoticons/emotion-6.gif)
I've always thought that a UML-driven approach makes the most sense. Something like a Visio model or some other tool. I've not used Rational or any of the other high-end suites but I would imagine that some form of code-gen exists in these tools. So far, I have not found anything within my price range.
From: Tom Cooley [mailto:cslanet@lhotka.net]
Sent: Friday, June 30, 2006 8:53 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] What does Rocky use for code generation?
RockfordLhotka:
... the vast majority of OO designers end up falling into the data-centric pit. ...No offense meant, but that statement had me falling out of my chair laughing!Why?Because for the last 20 years, it's been my experience that the vast majority of Entity-Relationship designers end up falling into the behavior modeling pit!Maybe they should all exchange job responsibilities and we could all be happier with the designs we get saddled with.
From: david.wendelken [mailto:cslanet@lhotka.net]
Sent: Friday, June 30, 2006 11:55 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: What does Rocky use for code generation?... the vast majority of OO designers end up falling into the data-centric pit. ...No offense meant, but that statement had me falling out of my chair laughing!Why?Because for the last 20 years, it's been my experience that the vast majority of Entity-Relationship designers end up falling into the behavior modeling pit!Maybe they should all exchange job responsibilities and we could all be happier with the designs we get saddled with.
So the home grown code generation approach works very well, BUT....
My concern is that code generation seems to be missing the behaviour aspect of OO and I am wondering how you can get that from meta data or ER diagrams.
You can only take automated code generation from an ERD a certain distance, and then that's it.
(It's farther than many people think, particularly if you supplement it with a behaviour-oriented meta-model that contains keywords or phrases to watch out for in the entity, attribute or relationship names.)
For example, I once wrote a program that would deduce candidate business rules from a data model. Example: rules like start<something> or begin<something> needs to be less than or equal to end<something>. I identified quite a few commonly recurring business rule patterns and would load the candidate rules into a meta-structure (where I could approve/disapprove them). Other candidate rules would include a no-overlapping records rule: identified by a table that contained a multi-column primary or unique key, where the leading portion of the key was an foreign key to the parent table and the trailing columns contained a start<something> or begin<something> kind of column name. Basically, the rule finder was a specification generator. From there, a code generator build the data access layer with its associated validation logic. (No complaints about where the code was - I wasn't using OO languages then. :)
With a little extra data stored about the relationships and a meta-data keyword repository, it's fairly straightforward to deduce which entities need to be maintained from the same screen. For example, Invoice Header and Invoice Line Item will often be maintained together, whereas Invoice Header and Invoice Type will not. That can be deduced because although all three entities share the same root word (Invoice) and would be connected via a chain of one-to-many relationships - Invoice Type contains a word that denotes a category or grouping of meta-data about Invoices, whereas Invoice Header does not. (It could be tuned by placing a <put them together> or <split them apart> code in the relationship meta-data.) I would pull these candidate maintenance screen data elements out of a data model via a utility program and put them into a meta-model that defined the screens' purpose and data usages. From there, further automated transformations (supplemented with manual enhancements and special hand-coded business logic) would turn them into code.
Now that I'm in the .Net world instead of the Oracle Forms world, I'm having to re-build my repository and code generation infrastructure. I'm looking for some good xml or relational meta-models that are already in use for holding object specifications - or I'll roll my own if need be.
(Feel free to point me in the right direction!)
I'm planning on adapting the techniques I used to mine an ERD to build candidate OO business object and maintenance/review screen specifications. From there, I'll supplement the meta-model by hand and by utility, then generate the code. CodeSmith looks to be an affordable way to short-circuit some of that work. :)
The key for me is to find my sea-legs with OO-based design. The CSLA book and forum have really helped me get a better grip on good OO design, and that will help guide me in building my new specification generators.
Rocky is dead on in his reply in my experience.
In my opinion if you rely heavily on code generation you are either ignorant of any usability or user experience concerns or are just too lazy to care.
Light use to automate repetitive areas of code that don't face the user is a different story but no great, modern, task oriented app was ever or ever will be generated entirely from a database schema.
In my opinion your answer shows a lot more ignorance than my question did. It's public forum not a 'court" to decide who is lazy or igonrant.
if you dont have a professional answer you dont have to reply to my questions, you can keep your 'high' opinions to yourself. I can start using all kinds of words too but I won't, its just not mature.
Sorry Ashraf, I did not in any way intend an insult. I used the word ignorant in the dictionary sense. I apologize if you were offended and stick by my remarks.
I do not mind being called ignorant, I readily admit I'm ignorant on many things and that there is nothing wrong with being ignorant, it's when you think you know it all that you are in trouble. :)
If you knew my background and the long complicated route I came to that point of view and the direct correlation between the roof over my head and how easy my software is to use to my end users you would perhaps respect my opinion a little more but I won't waste time trying to convince any one, time will do that inevitably for those that care about the end user and correct task oriented user interface design.
Again I apologize if you felt insulted, I did not mean to direct an insult at you, I do freely admit to directing any insult to the concept of code generation in general, unless it's used extremely sparingly in the correct situation.
No hard feelings, although this is an old thread but I got interested in it because of Rocky's reply (given below)
Yes, Magenic has a code generator called FBOG. Actually two of them, neither based on a custom generation engine. The first one was for CSLA 1.x and uses the code DOM, the second is for 2.0 and uses straight text output to escape the limitations of the code DOM.
These generators are built with the intent of augmenting Magenic's consultants as they work on projects, and the generator stays behind with the client when our consultants leave. But my point is that they aren't designed for "casual use" like CodeSmith; meaning no docs, a UI that lacks polish, etc. The tools aren't designed to compete with other code-generators, but rather to allow Magenic to compete with lower-cost consulting firms.
Which is a really long-winded way of heading off the next question, which is whether I can make FBOG available. I can't. Magenic owns it, not me, and they provide it as part of their consulting services only.
What I've been working on, off and on, is trying to come up with a new language for describing objects. Perhaps I'm on a fool's errand, but I look at the amount of code required to write an object, even with CSLA, and I think it is ridiculous. If you go through your code and identify only the lines of code that perform actual business functions - that have actual business value - you'll find that it is perhaps 4%. The rest of the lines of code are mandated by C# or VB or ADO.NET or Windows Forms or Web Forms or whatever. All "plumbing", and none of it valuable to the business need.
How does this tie into code-gen? A compiler is merely a fancy code generator. If I can come up with a more concise language to describe business objects (at least CSLA business objects), then I can code-gen CIL directly by creating a compiler for my language.
Thus far though, I have not been happy with any results 
" />
JCardina, In my opinion CRUD code generation is not helpful but like Rocky mentioned above there may be some oppurtunities for code generation.
have a good weekend!
JCardina, In my opinion CRUD code generation is not helpful but like Rocky mentioned above there may be some oppurtunities for code generation.
have a good weekend!
Why don't you give a try to CslaGenFork? There is a fresh Nightly Build 2011.06.23
Ok , I am really interested in knowin what happend to the code generation tool Rocky was trying to build 
I didn't pursue that option. There are some really good code generators out there, several of which include templates for (or directly target) CSLA .NET.
I'd much rather foster a code generation ecosystem around CSLA than attempt to become a competitor to those generators. I think that's better for CSLA and for the community as a whole.
I am sorry I don't follow what does a "code generation ecosystem" mean? 
, I do like the sound of it.
No offense meant please, I think I just like the term.
Copyright (c) Marimer LLC
