Codesmith + NetTiers, or LLBGen Pro...

[HankWangford]

EntityBroker

Another .Net option above llblgen is EntityBroker from thona. This guy is a great source of knowledge on asp.net forums and other blogs and his tool is pretty good.
http://www.thona-consulting.com/cont...itybroker.aspx

[Cowboy Bob]

For those with more of a Java inclination, AndroMDA is very good - http://www.andromda.org/

EDIT : Looks like they support .NET too in the latest release - http://team.andromda.org/contrib/starting-dotnet.html

[mcquiggd]

Have to admit ive been using the Enterprise library for some time, and its a major step up from the older Application Blocks... I worked for the company that wrote most of it with MS, Accenture and others and met the engineering team in Seattle - very smart guys, and some advanced 'assets' built around this foundation.

Configuration, Caching, and Data Access aspects are pretty handy.

[scotspine]

don't have 3 days at the mo, but to get back to mcggd's question, i think codesmith + nettiers looks like a good combo.


btw - what's buggy about the enterprise library?

[TheMonkey]

Seriously with a bit of thought it only took me about 3 days to knock it up.

[scotspine]

ouch!

[TheMonkey]

cool - gimme!

Write your own!

[scotspine]

cool - gimme!

[TheMonkey]

how does it handle hierarchical data?

Two ways:

1. Manual loading of collections on demand

public List<Category> SubCategories {
    get { 
        if (_subcats == null) {
           _subcats = this.BuildCollection(DAL.Category_SelectSubCategories(this.categoryId));
        }
        return _subcats;
    }
}

2. Using a "builder" to build the heirarchy from a single DataTable.

3. Builder with Nested sets.

You can choose depending on the requirement

[scotspine]

how does it handle hierarchical data?

[TheMonkey]

Not sure how it works better compared to or mappers like llblgen which has gone through many iterations and has a huge user test base. Surely the code it generates will contain less bug's that a greenfield hand coded data/entity layer.

LLBLGEN certainly saves hours and hours of boring hand cranking of dal methods and crud stored procs.

Wins my vote anytime, clients are very happy when you can demonstrate real visible functionality in days rather than two weeks of pure data layer coding.

Yeah you get less bugs (well the same bugs consistently) but sometimes you hit brick walls. I used CodeSmith on something a couple of years back and I assure you that I ended up spending more time working around stuff than doing work. If you know how to put everything together and have a basic library of data access functionality (similar in function to good old SqlHelper), you can knock up something in no time at all.

I'll have a look at LLBLGEN but I'm usually biased towards manual code. I have written a winforms app to build the DAL sprocs - the sproc/c# interface is manually written but it's simple. Some insight into my twisted brain:

DAL (null is an array of SqlParameters below if you want params)

public IDataReader Product_SelectAll() {
    return SqlEngine.ExecuteReader("Product_SelectAll", null);
}

Every object has a VIEW associated with it to load dependant data and a "convert reader to object state" function i.e.:

internal ObjectConstructor(IDataReader reader) : base(reader) {
  this.productId = reader.GetString(reader.GetOrdinal("Product_ProductID"));
  // load dependant category data
  this.category   = new Category(reader);
}

etc etc. Ultimately lazy and optimised for retrieval.

The base of the BusinessObject contains all the concurrency stuff, rule validation and persistence (~ 120k of code which has to be written once).

Rules are specified through attributes. When you persist the object, the whole object is scanned for attributes and validated and an exception thrown when something is wrong (with a collection of validation errors)

That framework is tested on something handling 8 million transactions a day so it's fairly reliable Whole thing is unit tested throughout as well and relies on no external tools, vendor lockin or licenses.

[HankWangford]

llblgen

Some thoughts:

1. Write your own code - it pays better and works better
2. Avoid Enterprise Library - it's buggy.

If you get into the mindset of "code generation" then you end up being a slave to the tools and lose a LOT of flexibility.

Not sure how it works better compared to or mappers like llblgen which has gone through many iterations and has a huge user test base. Surely the code it generates will contain less bug's that a greenfield hand coded data/entity layer.

LLBLGEN certainly saves hours and hours of boring hand cranking of dal methods and crud stored procs.

Wins my vote anytime, clients are very happy when you can demonstrate real visible functionality in days rather than two weeks of pure data layer coding.

[TheMonkey]

Some thoughts:

1. Write your own code - it pays better and works better
2. Avoid Enterprise Library - it's buggy.

If you get into the mindset of "code generation" then you end up being a slave to the tools and lose a LOT of flexibility.

[mcquiggd]

Currently looking at template based code generators, both for simple automation of repetitive 'boiler plate' code, and also the key elements of a company standard architecture...

I've previously used Codesmith to generate the basic Stored Procedures, Data Access Layer and base classes for Business Entities... and was happy with the result.

Now that CodeSmith is closely associated with NetTiers, it seems to have quite a few 'ticks in the box' - use of the Enterprise Library for Data Access / Configuration etc, basic Unit Test generation, and simple 'admin' type ASP.Net interfaces for lookup tables etc.

I have no experience of LLBGen Pro, which seems to be the other preferred choice... advocates claim it is just as flexible, but more specialised as an ORM generator.

Does anyone here have experience they would care to share of either / both / an alternative approach (DeKlarit seemed interesting)?


Part 2: Also, there seems to be some debate regarding architecture, e.g. NetTiers looks at db tables and produces:

Stored Procedures or Dynamic SQL
|
Wrappers for db calls via Enterprise Libraries DAAB
|
Abstract Classes for Business Entities
|
One-time generation of Concrete Business Entities

... which to me seems very logical, as when code is regenerated, you dont lose your concrete implementations of the Business Entities that contain all your business logic, and you just alter them accordingly. Another developer I worked with objected to this, saying 'partial classes were the answer'... personally I see those as simply ways to organise code rather than a logical separation, so could not see his point

Any comments....?