Can LLBLGen go from Model --> Data?
Joined: 21-May-2008
Joined: 21-May-2008
Joined: 16-Nov-2006
Joined: 18-Apr-2006
Joined: 30-Apr-2006
tangent wrote:
I use ER/Studio to do the same thing basically, create a conceptual model and then generate a physical sql data model. The only problem is that in my code I want to use the conceptual model also, not the physical model which is mirrored by the LLBL entities. This is one of the most common arguments in favor of NHibernate over LLBL that I hear from the DDD/alt.net community, and I tend to agree with them.
E/R models are 1:1 projections of table definitions. However if you create a NIAM/ORM model, you're 1 level above that and you then can model inheritance for example, things which aren't possible in E/R model. LLBLGen Pro reverse engineers the table definitions to the NIAM/ORM abstraction level, not the E/R abstraction level.
What DDD people forget to tell you is that the thoughts going into the design of a 'Customer' table is the same as when designing the Customer entity class: both are projections of an abstract entity definition. If not, why did someone design the class or table the way it is? As that's then an unanswerable question.
As NIAM/ORM model is a model which has lost traction in the last few years and tooling isn't really there, we've recognized that to be able to properly reverse engineer a datamodel, the datamodel itself has to be correct (i.e. a projection of an abstact entity model at the level of NIAM/ORM). That's not always the case, simply because the tooling isn't there: people start writing table DDL SQL and thus doing the projection of the abstract entity manually.
So in v3 we'll focus on this main point: the definition of the model is the central point of the application. You can still reverse engineer it from an existing db, but you can also create it inside the designer.
I always find it sad to see that some DDD focussed people forget that what Evans meant with DDD wasn't something related to repositories etc., but something related to how you should position the domain specific knowledge inside your project. I.o.w.: it doesn't matter which projection you pick (class or table) as long as it is a projection of a definition which is known inside the domain.
Cooking up entity classes behind the keyboard is as bad as cooking up tables behind the keyboard: first think about the theoretical basis for the table or class: why is there a need for a 'Customer' class? What attributes (fields) should it have? To which other entities does it relate? Is it a specialization of a known entity? (inheritance). These things aren't something you can cram into your customer class or table definition, as when you leave the project, that information is lost. It has to be in a model, in whatever format you want to store that (as model doesn't have to mean: picture in visio)
That's also my main point in my last weeks blogpost about the entity framework: of course you should work with the conceptional model in your code: but with every O/R mapper you can do that. The thing is: how do you create that conceptional model? If you manually create the tables in the schema, and you then want to map an inheritance hierarchy on that schema and it's not possible because the tables aren't suitable for inheritance, it's a typical example of a faulty projection of a conceptional model onto a table space.
The problems arise when people start claiming that an entity inside the DB is something else than an entity inside memory: it's impossible that that's true. The main reason is that the data has the same meaning, otherwise you can't reason over the data in memory: inside the APPLICATION the entity instance (data) has a meaning, it represents something: that group of constants forms a customer, or an order. If the data suddenly means something else when it crosses an artificial border, something is seriously wrong: the question then arises: where's the conversion and why is it necessary? I.o.w.: is the abstract entity definition of 'customer' different for the in-memory entity as it is for the db entity? If so: why are there 2 different abstract entity definitions in the same application? Isn't it so that there's just 1 domain?
I think the reason why some people try to make this so hard to understand is that they really want to work from the keyboard, cook things up while they're typing. After all, spending long hours thinking about what you're doing isn't everyone's favorite topic 
.
That said, I still prefer LLBL to NHibernate. I juse simple custom templates to generate interfaces for each entity which I then strip down to create a clean domain model, rather than exposing the entities directly. It is a bit more work but still much easier than maintaining hibernate mapping files by hand IMHO =)
Joined: 30-Apr-2006