LLBLGenPro and Domain Driven Design

[Casey Manus]

All,

We are writing a .net application and have chosen Frans Bauma's LLBLGen
Pro as our ORM tool. This tool will generate entity classes for each
table in the database. According to the documentation, this tool uses
the classic Peter Chen deffinition of "entity", not the Fowler/Evans
definition.
I am stuggling to figure out how the LLBLGen Pro generated classes do
not fulfill the halmarks of an entity in the Evans Classification.

So do we need a layer that tranforms the LLBLGen Pro generated entities
into a different class that fulfills the role of an entity in the
domain model or is it accepted practice to use an entity from an ORM
tool in DDD?






------------------------ Yahoo! Groups Sponsor --------------------~-->
Yahoo! Groups gets a make over. See the new email design.
http://us.click.yahoo.com/hOt0.A/lOaOAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->

[Frans Bouma]

Hi Casey,

Post by Casey Manus
We are writing a .net application and have chosen Frans Bauma's LLBLGen
Pro as our ORM tool. This tool will generate entity classes for each
table in the database. According to the documentation, this tool uses
the classic Peter Chen deffinition of "entity", not the Fowler/Evans
definition.
I am stuggling to figure out how the LLBLGen Pro generated classes do
not fulfill the halmarks of an entity in the Evans Classification.

It's more of a semantic word game really. If you look at a 'class',
like 'customer' and say 'that's my entity', it's not really the same thing as
what Chen described, so that's what I meant with the distinction remark.

Typically, 'entity' means the relation formed by attributes, like a
customer entity with the attributes 'Id', 'CompanyName' and 'Location'. If you
look at it at the level of NIAM/ORM (http://www.orm.net) you'll see that that
abstract level is actually the same starting point from which you'd start
creating database tables on one hand and entity classes on the other, also
because at that level you can define inheritance.

Post by Casey Manus
So do we need a layer that tranforms the LLBLGen Pro generated entities
into a different class that fulfills the role of an entity in the
domain model or is it accepted practice to use an entity from an ORM
tool in DDD?

I don't think you need a layer to transform the entities into your own
objects. You could for example write repositories which provide the
functionality to obtain entities of a given type or graphs of entities, and if
you for example use our adapter paradigm, all persistence logic is factored
out in a separate project so you don't have persistence oriented code in your
own code.

LLBLGen Pro doesn't match for 100% the DDD principles, as it uses a
central base class for entities and uses code generation to write some code
for you to make them work nicely with other parts of the .NET framework. This
thus means that your entity classes aren't for 100% clean from the o/r mapper
used. IMHO this is ok, as nowadays an o/r mapper is hardly about persistence
alone (ok, perhaps still in Redmond ;)) but are more and more entity
management frameworks which take care of a lot of the things you run into when
dealing with entity objects.

There are a couple of ways to 'inject' the code necessary to make that
all possible:

0) write everything by hand (yeah right ;))
1) runtime dynamic proxy objects
2) bytecode/IL manipulation at compile time
3) code generation

We've opted for option 3) as it's the most clear one: you see what you
get. Option 1) is intrusive as well, as it requires factories to create dyn.
proxy objects, virtual methods etc.. Option 2) is getting more and more ground
in .NET nowadays with tools getting more mature and we're looking at option 2)
as well to generate the code at compile time, weave it into your code.

Hope this helps. Feel free to ask more questions here or on our
support forums :)

Frans

------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------







------------------------ Yahoo! Groups Sponsor --------------------~-->
Something is new at Yahoo! Groups. Check out the enhanced email design.
http://us.click.yahoo.com/kOt0.A/gOaOAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->

[joethebigshmoe]

Casey and Frans,

Tell me what I am missing.
We created a little utility with very little effort that can generate
a DTO object and its matching collection by pointing at any table in
the database. Like Casey seemed to elude to, we also use these DTOs
to build our business objects.

This system has worked well for a long time and I don't know of any
complaints on our teams. It seems our little utility does what
LLBLGen does, however the code it produces follows our standards and
naming conventions which is a nice benefit.

Casey says...
[So do we need a layer that transforms the LLBLGen Pro generated
entities into a different class that fulfills the role of an entity
in the domain model]
Frans says...
[I don't think you need a layer to transform the entities into your
own]
My first thought was Yes! Otherwise you end up with an object model
based on data tables...yuck.

Tell me what I am missing.

Thanks,

Joe




------------------------ Yahoo! Groups Sponsor --------------------~-->
Check out the new improvements in Yahoo! Groups email.
http://us.click.yahoo.com/4It09A/fOaOAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->

[Frans Bouma]

Hi Joe,

Post by joethebigshmoe
Tell me what I am missing.
We created a little utility with very little effort that can generate
a DTO object and its matching collection by pointing at any table in
the database. Like Casey seemed to elude to, we also use these DTOs
to build our business objects.
This system has worked well for a long time and I don't know of any
complaints on our teams. It seems our little utility does what
LLBLGen does, however the code it produces follows our standards and
naming conventions which is a nice benefit.

I don't think your little utility manages the entities in the system,
saves graphs in one go, provides an OO, compile time checked filtering system
etc.

that's ok, if DTO's which match your tables is all you need, one could
use 1 little template in any code generator which could pull meta-data from a
db and put it to work with that template.

Post by joethebigshmoe
Casey says...
[So do we need a layer that transforms the LLBLGen Pro generated
entities into a different class that fulfills the role of an entity
in the domain model]
Frans says...
[I don't think you need a layer to transform the entities into your
own]
My first thought was Yes! Otherwise you end up with an object model
based on data tables...yuck.

what do datatables have to do with it?

FB



------------------------ Yahoo! Groups Sponsor --------------------~-->
Yahoo! Groups gets a make over. See the new email design.
http://us.click.yahoo.com/hOt0.A/lOaOAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->

[Joe A. Reddy]

Frans,

Thanks for following up.

Post by joethebigshmoe

"what do datatables have to do with it?"

The original post from Casey said, "This tool will generate entity
classes for each
table in the database."



He then asked if he had to convert them to his entity objects. I would
say yes as classes that just matched data tables do not represent the
domain.

Post by joethebigshmoe

"saves graphs in one go, provides an OO compile time checked filtering

system"

This is what I did not know I was missing, it is all foreign to me. I
will have to look into what you mean by graphs and OO compile time
checked filtering system. Sounds fancy. My DTOs are just that, they are
not object-oriented anything. They are dumb data transfer objects that
just contain data. They never go beyond the code that translates one or
more of them into OO business objects.



Thanks,



Joe





-----Original Message-----
From: ***@yahoogroups.com
[mailto:***@yahoogroups.com] On Behalf Of Frans Bouma
Sent: Thursday, March 01, 2007 2:19 PM
To: ***@yahoogroups.com
Subject: RE: [domaindrivendesign] Re: LLBLGenPro and Domain Driven
Design



Hi Joe,

Post by joethebigshmoe
Tell me what I am missing.
We created a little utility with very little effort that can generate
a DTO object and its matching collection by pointing at any table in
the database. Like Casey seemed to elude to, we also use these DTOs
to build our business objects.
This system has worked well for a long time and I don't know of any
complaints on our teams. It seems our little utility does what
LLBLGen does, however the code it produces follows our standards and
naming conventions which is a nice benefit.

I don't think your little utility manages the entities in the system,
saves graphs in one go, provides an OO, compile time checked filtering
system
etc.

that's ok, if DTO's which match your tables is all you need, one could
use 1 little template in any code generator which could pull meta-data
from a
db and put it to work with that template.

Post by joethebigshmoe
Casey says...
[So do we need a layer that transforms the LLBLGen Pro generated
entities into a different class that fulfills the role of an entity
in the domain model]
Frans says...
[I don't think you need a layer to transform the entities into your
own]
My first thought was Yes! Otherwise you end up with an object model
based on data tables...yuck.

what do datatables have to do with it?

FB

[Frans Bouma]

Hi Joe,

"what do datatables have to do with it?"

The original post from Casey said, "This tool will generate entity classes

for

each table in the database."
He then asked if he had to convert them to his entity objects. I would say

yes

as classes that just matched data tables do not represent the domain.

true, though llblgen pro reverse engineers the entity model to a level
above E/R, thus with inheritance, which is the same level as where you start
with when defining domain classes.

"saves graphs in one go, provides an OO compile time checked filtering

system"
This is what I did not know I was missing, it is all foreign to me. I will
have to look into what you mean by graphs and OO compile time checked
filtering system. Sounds fancy. My DTOs are just that, they are not object-
oriented anything. They are dumb data transfer objects that just contain

data.

They never go beyond the code that translates one or more of them into OO
business objects.

DTO's can be very handy in a lot of situations, like in communication
with webservices, where object graphs aren't really useful but message-based
DTO's are.

compile time checked filtering system means that you can write filter
code which is compile time checked, thus not string based, but with real
objects.

graphs mean this:
you have a customer object, and you add a new Order object with new
OrderDetails objects to its Orders collection. You then save the whole thing
recursively and all PK's and FK fields are synced automatically in the
entities for you.

Of course, now someone will step in and say "thou shall not say 'PK'
or 'FK' and thou shall only reference aggregate roots", though I then wonder
how these people write a simple master-detail form in .NET

FB





------------------------ Yahoo! Groups Sponsor --------------------~-->
Yahoo! Groups gets a make over. See the new email design.
http://us.click.yahoo.com/hOt0.A/lOaOAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->

[Casey Manus]

Frans,

One seemingly missing feature, or rather "feature I can't find
maybe", is the ability to define a "composite" entity in the
designer. By this I mean, start with 1 entity, add columns from
related entity based on a join (which may or may not be on
primary/foreign keys) and update all the "composited" entities during
save.
I know you could easily define this as an entity view...but then it
would be readonly. This, in addition to the existing sub-typing could
IMHO complete our ability to disconnect the object model from the
underlying database model. How hard would it be to extend the
designer to support this, it seems like maybe most of the runtime
support is there, but I am sure that would require some updates
too...maybe not.

Thanks,

Casey

Post by Frans Bouma
Hi Joe,

Post by Joe A. Reddy

"what do datatables have to do with it?"

The original post from Casey said, "This tool will generate

entity classes

Post by Frans Bouma
for

Post by Joe A. Reddy
each table in the database."
He then asked if he had to convert them to his entity objects. I would say

yes

Post by Joe A. Reddy
as classes that just matched data tables do not represent the domain.

true, though llblgen pro reverse engineers the entity model

to a level

Post by Frans Bouma
above E/R, thus with inheritance, which is the same level as where you start
with when defining domain classes.

Post by Joe A. Reddy

"saves graphs in one go, provides an OO compile time checked filtering

system"
This is what I did not know I was missing, it is all foreign to me. I will
have to look into what you mean by graphs and OO compile time checked
filtering system. Sounds fancy. My DTOs are just that, they are not object-
oriented anything. They are dumb data transfer objects that just contain

data.

Post by Joe A. Reddy
They never go beyond the code that translates one or more of them into OO
business objects.

DTO's can be very handy in a lot of situations, like in

communication

Post by Frans Bouma
with webservices, where object graphs aren't really useful but

message-based

Post by Frans Bouma
DTO's are.
compile time checked filtering system means that you can

write filter

Post by Frans Bouma
code which is compile time checked, thus not string based, but with real
objects.
you have a customer object, and you add a new Order object with new
OrderDetails objects to its Orders collection. You then save the whole thing
recursively and all PK's and FK fields are synced automatically in the
entities for you.
Of course, now someone will step in and say "thou shall not

say 'PK'

Post by Frans Bouma
or 'FK' and thou shall only reference aggregate roots", though I then wonder
how these people write a simple master-detail form in .NET
FB

------------------------ Yahoo! Groups Sponsor --------------------~-->
See what's inside the new Yahoo! Groups email.
http://us.click.yahoo.com/0It09A/bOaOAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->

[Frans Bouma]

Hi Casey,

Post by Casey Manus
One seemingly missing feature, or rather "feature I can't find
maybe", is the ability to define a "composite" entity in the
designer. By this I mean, start with 1 entity, add columns from
related entity based on a join (which may or may not be on
primary/foreign keys) and update all the "composited" entities during
save.
I know you could easily define this as an entity view...but then it
would be readonly. This, in addition to the existing sub-typing could
IMHO complete our ability to disconnect the object model from the
underlying database model. How hard would it be to extend the
designer to support this, it seems like maybe most of the runtime
support is there, but I am sure that would require some updates
too...maybe not.

The only multi-table entity mapping we support is through inheritance.
We didn't support random multi-table mapping for the same reason why most big
RDBMS databases don't support updates on a view to more than one table: to be
able to perform CUD queries on multiple tables from a single entity, the PK of
all tables involved has to be known, and for insert queries, all fields which
are not nullable have to be available in the entity. This is a restriction
which makes the feature less appealing than initially anticipated because the
reason this feature is sometimes needed is because one or more of these
restrictions can't be fulfilled.

We do support mapping a field in entity E onto a related field in an
related entity F, e.g. customer.CompanyName in the Order entity. This does
mean though that customer and order are still separated entities.

FB



------------------------ Yahoo! Groups Sponsor --------------------~-->
Something is new at Yahoo! Groups. Check out the enhanced email design.
http://us.click.yahoo.com/kOt0.A/gOaOAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->

[Casey Manus]

Frans,

Although there would be alot of restrictions, such as the fact that
your composite entity would have to expose all the non-nullable
fields that do not have defaults; it still seems like this is the
final piece to being able to decouple the data model and object
model. I will give you the example I am working with

Our database has 2 tables (address and phone (note phone has a
subtype of fax, too) which can store contact information for any
person. We want to be able able to use this as "contact" and not two
(or 3 with "fax" involved) seperate entities.

In this case, the tables aren't dependant on each other, but are
dependant upon Person, which makes some of the problems you mentioned
somewhat moot, other than the fact you would want to ensure both
tables are updated in a single transaction.

Thoughts?

-Casey

Post by Frans Bouma
Hi Casey,

Post by Casey Manus
One seemingly missing feature, or rather "feature I can't find
maybe", is the ability to define a "composite" entity in the
designer. By this I mean, start with 1 entity, add columns from
related entity based on a join (which may or may not be on
primary/foreign keys) and update all the "composited" entities during
save.
I know you could easily define this as an entity view...but then it
would be readonly. This, in addition to the existing sub-typing could
IMHO complete our ability to disconnect the object model from the
underlying database model. How hard would it be to extend the
designer to support this, it seems like maybe most of the runtime
support is there, but I am sure that would require some updates
too...maybe not.

The only multi-table entity mapping we support is through

inheritance.

Post by Frans Bouma
We didn't support random multi-table mapping for the same reason why most big
RDBMS databases don't support updates on a view to more than one table: to be
able to perform CUD queries on multiple tables from a single

entity, the PK of

Post by Frans Bouma
all tables involved has to be known, and for insert queries, all fields which
are not nullable have to be available in the entity. This is a

restriction

Post by Frans Bouma
which makes the feature less appealing than initially anticipated because the
reason this feature is sometimes needed is because one or more of these
restrictions can't be fulfilled.
We do support mapping a field in entity E onto a related

field in an

Post by Frans Bouma
related entity F, e.g. customer.CompanyName in the Order entity. This does
mean though that customer and order are still separated entities.
FB

------------------------ Yahoo! Groups Sponsor --------------------~-->
Great things are happening at Yahoo! Groups. See the new email design.
http://us.click.yahoo.com/lOt0.A/hOaOAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->

[Frans Bouma]

Hi Casey,

Post by Casey Manus
Although there would be alot of restrictions, such as the fact that
your composite entity would have to expose all the non-nullable
fields that do not have defaults; it still seems like this is the
final piece to being able to decouple the data model and object
model. I will give you the example I am working with
Our database has 2 tables (address and phone (note phone has a
subtype of fax, too) which can store contact information for any
person. We want to be able able to use this as "contact" and not two
(or 3 with "fax" involved) seperate entities.
In this case, the tables aren't dependant on each other, but are
dependant upon Person, which makes some of the problems you mentioned
somewhat moot, other than the fact you would want to ensure both
tables are updated in a single transaction.
Thoughts?

what is the identifying field / attribute for Contact? Also, what
happens if there are 10 address rows and 20 phone rows?

This is often a problem that's not really solvable. Instead people can
also use Person and traverse the information via the associations. YES, that
pollutes your object model with how it's stored in the relational database,
but frankly, that's reality: the entities defined in the entity model are
really address, phone and fax, not contact. That would require the grouping of
all attributes of address, phone and fax into a single entity and I don't see
that happening as phone and address attributes aren't related to eachother, so
actually can't even be placed inside a single entity. This is also the base
for my question: what happens when there are less (or more!) address rows than
phone rows. Are some of the fields in contact then NULL or duplicated?
Semantically one would say address is leading and phone is following but
that's not always true anymore.

FB

Post by Casey Manus
-Casey
<mailto:domaindrivendesign%40yahoogroups.com> , "Frans Bouma"

Post by Frans Bouma
Hi Casey,

Post by Casey Manus
One seemingly missing feature, or rather "feature I can't find
maybe", is the ability to define a "composite" entity in the
designer. By this I mean, start with 1 entity, add columns from
related entity based on a join (which may or may not be on
primary/foreign keys) and update all the "composited" entities

during

Post by Frans Bouma

Post by Casey Manus
save.
I know you could easily define this as an entity view...but then

it

Post by Frans Bouma

Post by Casey Manus
would be readonly. This, in addition to the existing sub-typing

could

Post by Frans Bouma

Post by Casey Manus
IMHO complete our ability to disconnect the object model from the
underlying database model. How hard would it be to extend the
designer to support this, it seems like maybe most of the runtime
support is there, but I am sure that would require some updates
too...maybe not.

The only multi-table entity mapping we support is through

inheritance.

Post by Frans Bouma
We didn't support random multi-table mapping for the same reason

why most big

Post by Frans Bouma
RDBMS databases don't support updates on a view to more than one

table: to be

Post by Frans Bouma
able to perform CUD queries on multiple tables from a single

entity, the PK of

Post by Frans Bouma
all tables involved has to be known, and for insert queries, all

fields which

Post by Frans Bouma
are not nullable have to be available in the entity. This is a

restriction

Post by Frans Bouma
which makes the feature less appealing than initially anticipated

because the

Post by Frans Bouma
reason this feature is sometimes needed is because one or more of

these

Post by Frans Bouma
restrictions can't be fulfilled.
We do support mapping a field in entity E onto a related

field in an

Post by Frans Bouma
related entity F, e.g. customer.CompanyName in the Order entity.

This does

Post by Frans Bouma
mean though that customer and order are still separated entities.
FB

------------------------ Yahoo! Groups Sponsor --------------------~-->
Check out the new improvements in Yahoo! Groups email.
http://us.click.yahoo.com/4It09A/fOaOAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->

[Casey Manus]

Frans,

Thanks for the feedback. The problem is that there is an implied
relationship, but no relationship explicitly exists in the data
model. A teak to the data model would probably be needed to do what
we are asking.

-Casey

Post by Frans Bouma
Hi Casey,

Post by Casey Manus
Although there would be alot of restrictions, such as the fact that
your composite entity would have to expose all the non-nullable
fields that do not have defaults; it still seems like this is the
final piece to being able to decouple the data model and object
model. I will give you the example I am working with
Our database has 2 tables (address and phone (note phone has a
subtype of fax, too) which can store contact information for any
person. We want to be able able to use this as "contact" and not two
(or 3 with "fax" involved) seperate entities.
In this case, the tables aren't dependant on each other, but are
dependant upon Person, which makes some of the problems you

mentioned

Post by Frans Bouma

Post by Casey Manus
somewhat moot, other than the fact you would want to ensure both
tables are updated in a single transaction.
Thoughts?

what is the identifying field / attribute for Contact? Also,

what

Post by Frans Bouma
happens if there are 10 address rows and 20 phone rows?
This is often a problem that's not really solvable. Instead

people can

Post by Frans Bouma
also use Person and traverse the information via the associations. YES, that
pollutes your object model with how it's stored in the relational database,
but frankly, that's reality: the entities defined in the entity model are
really address, phone and fax, not contact. That would require the grouping of
all attributes of address, phone and fax into a single entity and I don't see
that happening as phone and address attributes aren't related to eachother, so
actually can't even be placed inside a single entity. This is also the base
for my question: what happens when there are less (or more!)

address rows than

Post by Frans Bouma
phone rows. Are some of the fields in contact then NULL or

duplicated?

Post by Frans Bouma
Semantically one would say address is leading and phone is

following but

Post by Frans Bouma
that's not always true anymore.
FB

Post by Casey Manus
-Casey
<mailto:domaindrivendesign%40yahoogroups.com> , "Frans Bouma"

Post by Frans Bouma
Hi Casey,

Post by Casey Manus
One seemingly missing feature, or rather "feature I can't find
maybe", is the ability to define a "composite" entity in the
designer. By this I mean, start with 1 entity, add columns from
related entity based on a join (which may or may not be on
primary/foreign keys) and update all the "composited" entities

during

Post by Frans Bouma

Post by Casey Manus
save.
I know you could easily define this as an entity view...but then

it

Post by Frans Bouma

Post by Casey Manus
would be readonly. This, in addition to the existing sub-

typing

Post by Frans Bouma

Post by Casey Manus
could

Post by Frans Bouma

Post by Casey Manus
IMHO complete our ability to disconnect the object model from the
underlying database model. How hard would it be to extend the
designer to support this, it seems like maybe most of the runtime
support is there, but I am sure that would require some

updates

Post by Frans Bouma

Post by Casey Manus

Post by Frans Bouma

Post by Casey Manus
too...maybe not.

The only multi-table entity mapping we support is through

inheritance.

Post by Frans Bouma
We didn't support random multi-table mapping for the same reason

why most big

Post by Frans Bouma
RDBMS databases don't support updates on a view to more than one

table: to be

Post by Frans Bouma
able to perform CUD queries on multiple tables from a single

entity, the PK of

Post by Frans Bouma
all tables involved has to be known, and for insert queries, all

fields which

Post by Frans Bouma
are not nullable have to be available in the entity. This is a

restriction

Post by Frans Bouma
which makes the feature less appealing than initially

anticipated

Post by Frans Bouma

Post by Casey Manus
because the

Post by Frans Bouma
reason this feature is sometimes needed is because one or more of

these

Post by Frans Bouma
restrictions can't be fulfilled.
We do support mapping a field in entity E onto a related

field in an

Post by Frans Bouma
related entity F, e.g. customer.CompanyName in the Order entity.

This does

Post by Frans Bouma
mean though that customer and order are still separated

entities.

Post by Frans Bouma

Post by Casey Manus

Post by Frans Bouma
FB

------------------------ Yahoo! Groups Sponsor --------------------~-->
Great things are happening at Yahoo! Groups. See the new email design.
http://us.click.yahoo.com/lOt0.A/hOaOAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->