The effects of ORM in architecture and domain driven design

Hi,
I've just started a small web app, and I am using an ORM
product for DB
access, which is what I have been doing for the last 5
years. In the
beginning I had my own solution, but after leaving the
company I wrote it
for,  I did not take the code with me, and great products
emerged for .NET
like llblgen.
The thing is, for a small project, it is almost inevitable
for a developer
to quickly create a db schema, generate sql statements from
the db design
tool, and create the db, which if followed by reverse
engineering the db
with orm tools, and bind it to UI. It is the kind of thing
that I've done
maybe a hundred times or more.
The thing is, when I start with use cases, and a domain
model that does not
include any concerns for persistence, the results are
different. The uml
diagram I'm looking at uses inheritence, design patterns
etc, and if you do
not think about  persistence, the look of the code that uses
this model is
quite clean. It is more maintainable too.
Now this is a clash between two different approaches, where
domain info is
modelled first in db or in a domain model. The question is,
what is the best
way to merge these approaches? I am really happy about using
benefits of OO
in the domain model, but at the end I find myself writing a
"manager" layer
which connects domain classes to orm generated classes.
I am not sure if ORM should be responsible for more than
eliminating the gap
between relational paradigm and OO paradigm, and you see all
these resources
referring to ORM classes as domain classes. Check out any OO
design resource
or course, and you'll see that the modelling of a domain is
rarely performed
in DB world, where schemas and allowed db types are your
building tools.
Eclipse Modelling Framework seems to have a binding to
Hibernate for
example, which is a clear indication of seperating domain
model from ORM
classes, and I think I am in favor of this approach, for it
allows me to do
the design based on OO approach, and it also gives the
benefit of being able
to isolate myself from sql.
On the other hand, ORM based approach simply works! I think
I'm more
inclined to accept ORM (generated) classes as domain classes
when I'm under
time pressure and the app is small, and writing down the
connecting layer
between domain and orm layers when I have more time and the
project is
larger.
I'd love to hear what you think about this. How do you draw
the line? Which
approach is common in your shop?

Cheers
Seref

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Ah, you are definitely a good choice for discussing the
subject 

Ok. I agree with you to  a degree that I will not use inline
responses, but
I'll rather try to make my questions more specific.

Many of the advantages I'm trying to preserve by modelling
using design
patterns and common OO concepts, are about
"coding". More maintainable code
and more efficient changes to code (in terms of man hours)
is my primary
point which is in favor of OO approach.

This does not mean that you can't use DB concepts instead of
using OO
concepts in modelling a domain. After spending about 8 years
writing code
around and inside some very DB oriented apps, you learn to
respect the
outcomes of this approach.

I'm just saying that, by using DB concepts (types,
relations) as the primary
modeling approach, and generating OO code from this model,
we loose some of
the benefits of OO design. However, it is my opinion that
this loss is not
about the actual capability of the software, it is mostly
about the
efficiency of making changes to code, and up to a threshold
value (very hard
to determine), this is acceptable.

My request for comments is about the following scenario. By
adopting OO
based design for domain, you can choose to completely ignore
the requirement
for persistence, accept it as a service actually, and use
all the things
like inheritence, interface based design, particular
patterns etc..

After you've done this, you have a set of classes, and you
actually have two
choices.

1) you can now forget about all these classes, and design a
db schema based
model for the domain, as if you are doing the DB oriented
modelling. After
this you generate OO reflections of your DB model by reverse
enginering this
schema, and now you have two sets of "domain
classes". One set is build on
OO concepts, and the other one is mappings to OO concepts
from DB concepts.
A tool oriented summary is like this:

[Classes generated from UML] <------->[connector
layer/service/class]<------------> [classes generated
from DB
schema]<----------->[ORM
services]<--------->[DB]
Here, there is a possibility of overlapping, like very
similar classes in
both UML generated set and ORM generated set. But when
inheritence and other
OO concepts are used heavily in OO based set, the
distinction is usually
clear. Here, ORM based classes become kinda DTOs for DAOs,
where DAO pattern
is encapsulated in connector layer.
Do you think the architecture above is overkill? Do you
think that instead
of modelling DB by looking at the domain, we can model it as
using the class
designs as inputs? I am trying to see if I can justify the
appoarch above, I
guess the only way to do that is to give it a try in a
moderate sized
project, which I have at hand at the moment, but still your
opinions would
be quite valuable.
All the best
Seref
On Tue, Jul 22, 2008 at 3:48 PM, Frans Bouma
<perseus3xs4all.nl> wrote:

> Hi Seref,
>
> > I've just started a small web app, and I am using
an ORM product for DB
> > access, which is what I have been doing for the
last 5 years. In the
> > beginning I had my own solution, but after leaving
the company I wrote it
> > for,  I did not take the code with me, and great
products emerged for
> .NET
> > like llblgen.
>
>        
>
> > The thing is, for a small project, it is almost
inevitable for a
> developer
> > to quickly create a db schema, generate sql
statements from the db design
> > tool, and create the db, which if followed by
reverse engineering the db
> > with orm tools, and bind it to UI. It is the kind
of thing that I've done
> > maybe a hundred times or more.
>
>         Not only in small projects. Often a team
contains one or more DB
> architects who are in charge of designing and
maintaining the db schemas.
>
> > The thing is, when I start with use cases, and a
domain model that does
> not
> > include any concerns for persistence, the results
are different. The uml
> > diagram I'm looking at uses inheritence, design
patterns etc, and if you
> do
> > not think about  persistence, the look of the code
that uses this model
> is
> > quite clean. It is more maintainable too.
>
>         true, from a code perspective.
>
>        Though, one thing has to be realized: if you
design a class
> hierarchy
> like Person <- Customer, Person <- Employee etc.,
these types didn't fall
> out
> of the sky: they're physical definitions of abstract
entity types,
> projected
> onto program code.
>
>        This means that it doesn't matter if you write a
person and customer
> class or that you create a person and customer table:
both are projections
> of
> the same (!) abstract entity. The thing is: an abstract
entity is a
> definition
> of something which is recognized in reality. How you
create your code to
> deal
> with this definition is up to you, however it's wrong
to ignore the fact
> that
> the entity is simply something that is recognized in
reality, so modelling
> an
> entity model is really just modelling what's already
there: reality
> contains
> these entities already.
>
>        If a class diagram is created which contains
different types than
> the
> ones recognized in reality, it simply means a
conversion has to take place.
> Too many times developers assume that this conversion
takes place in an O/R
> mapper layer, but that's a mistake: the conversion has
to take place inside
> the code: the conversions I'm talking about are
actually projections: from
> one
> domain to the other. If the conversion doesn't take
place, you can't talk
> about 'customer' in the context of the program and if
the conversion isn't
> recognized as something required, one also can't talk
about 'customer' in
> the
> context of reality. And especially that second part is
where things go
> horribly wrong in a lot of application which consume
databases.
>
> > Now this is a clash between two different
approaches, where domain info
> is
> > modelled first in db or in a domain model. The
question is, what is the
> best
> > way to merge these approaches? I am really happy
about using benefits of
> OO
> > in the domain model, but at the end I find myself
writing a "manager"
> layer
> > which connects domain classes to orm generated
classes.
>
>         As long as your application logic deals with
entity types which are
> simply a physical representation of the abstract
definition, you can make
> decisions based on these entities with rules as
recognized in reality, e.g.
> based on interviews with the client, research of the
organization the
> application is for etc.
>
>        The advantage of having entity types which
represent elements
> recognized in reality is that your code mimics that of
what should be done
> in
> reality / is done in reality as well. I.o.w. you can
reason about what the
> logic should be done by simply looking at reality and
how processes work,
> should work, how information streams run, what
information is available
> etc.
>
>        Nowadays this is called 'domain oriented', in
earlier days there
> were
> different terms, but they all come done to the simple
fact that one should
> recognize what reality contains about the subject at
hand and use that
> information as the base of the software to build.
>
>        Never ever fall into the trap that the class
model is the
> representation of a) reality and b) what should be done
to make the
> software
> behave in reality as required.
>
> > I am not sure if ORM should be responsible for
more than eliminating the
> gap
> > between relational paradigm and OO paradigm, and
you see all these
> resources
> > referring to ORM classes as domain classes. Check
out any OO design
> resource
> > or course, and you'll see that the modelling of a
domain is rarely
> performed
> > in DB world, where schemas and allowed db types
are your building tools.
> > Eclipse Modelling Framework seems to have a
binding to Hibernate for
> > example, which is a clear indication of seperating
domain model from ORM
> > classes, and I think I am in favor of this
approach, for it allows me to
> do
> > the design based on OO approach, and it also gives
the benefit of being
> able
> > to isolate myself from sql.
>
>         Though, it's nothing more than dealing with the
overhead of
> text-based
> code which is a projection of the functionality
required: if the paradigm
> of
> the code changes, if the language changes (e.g. from C#
to haskell), the
> real
> program, the solutions to the problems recognized, the
functionality
> required,
> the entities recognized in reality which are the ones
to deal with aren't
> changing one bit.
>
>        Thinking in C# statements too often makes people
think that what
> they're typing in is the solution, is the
functionality, are the
> datastructures required, but they're projections of the
solution,
> functionality and datastructures required. Because
they're projections,
> your
> main focus first should be on the source of these
projections, which is
> what
> we're today call the domain model, entity models etc.
>
>        And these have little to do with code, class
models and the like.
>
> > On the other hand, ORM based approach simply
works! I think I'm more
> > inclined to accept ORM (generated) classes as
domain classes when I'm
> under
> > time pressure and the app is small, and writing
down the connecting layer
> > between domain and orm layers when I have more
time and the project is
> > larger.
> > I'd love to hear what you think about this. How do
you draw the line?
> Which
> > approach is common in your shop?
>
>         I wrote a couple of articles about this
subject, one is in Jimmy's
> book: 'The datamodel is the domain model' (I always
love the reactions of
> code-junkies when they see the title ;)) available
here:
>
> http://weblogs.asp.net/fbouma/arch
ive/2006/08/23/Essay_3A00_-The-Database-Mode
> l-is-the-Domain-Model.aspx<http
://weblogs.asp.net/fbouma/archive/2006/08/23/Essay_3A00_-The
-Database-Model-is-the-Domain-Model.aspx>
>        and I rehashed it abit in different wording
here:
>
> http://weblogs.asp.net/fbouma/arch
ive/2008/05/19/why-use-the-entity-framework-
> yeah-why-exactly.aspx<http://we
blogs.asp.net/fbouma/archive/2008/05/19/why-use-the-entity-f
ramework-yeah-why-exactly.aspx>
>
>        In v3 of LLBLGen Pro we'll do both approaches,
model first (dbschema
> follows entity model) and dbschema first (entity model
reverse engineered
> from
> dbschema), which both come down to simply build an
entity model + mappings
> +
> dbschema model, and it doesn't really matter which side
you started, you'll
> end up in that state anyway. Nice thing is that you can
directly
> communicate
> with domain experts _and_ database schema experts at
that level, as it's
> the
> abstraction level already defined a long time ago in
for example NIAM/ORM
> (object role modelling ;)), Yourdon and later on in a
set of different
> names
> by Evans.
>
>                FB
>
>
------------------------------------------------------------
------------
> 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#)
>
------------------------------------------------------------
------------
>
> ===================================
> This list is hosted by DevelopMentor(R)  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com

>

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

> Many of the advantages I'm trying to preserve by
modelling using design
> patterns and common OO concepts, are about
"coding". More maintainable code
> and more efficient changes to code (in terms of man
hours) is my primary
> point which is in favor of OO approach.

        If OO brings you better maintainable software in
this case, OO is a
good choice. If it gives you less maintainable software,
don't use OO. Using
OO doesn't give you a turnkey solution to maintainable
software, neither does
an API in a DB consisting of 10K procs, one has to WORK to
make software
maintainable, it has less to do with the paradigm used, but
more with the fact
that decisions made are made for a reason and that the
decisions made are
documented, that the alternatives and why they were rejected
are documented,
that answers to the simply question "Why?" is
answerable by a person who will
work on the software in 2015, when you're sitting in the sun
on the beach on
the Bahamas and cellphones are out of reach.

> I'm just saying that, by using DB concepts (types,
relations) as the primary
> modeling approach, and generating OO code from this
model, we loose some of
> the benefits of OO design.

        and those are?  Isn't the
code generated also OO? Mind you: your
client doesn't give a **** about how you wrote the software,
he just wants
software that solves his problems. So if you thought about a
fancy
architecture with a lot of services and all the latest
buzzwords, it's not
important. What's important is that what's used makes things
easier and better
to understand what's going on, i.o.w.: no surprises, no
traps.

        tables and fk constraints aren't the elements
classes are directly
based on. They're based on the reversed engineered model at
an abstraction
level ABOVE E/R model (so it can contain inheritance etc.).

> My request for comments is about the following
scenario. By adopting OO
> based design for domain, you can choose to completely
ignore the requirement
> for persistence, accept it as a service actually, and
use all the things
> like inheritence, interface based design, particular
patterns etc..

        Those are implemenatation specific elements, and can
work perfectly
fine with classes which represent entity definitions. After
all, every single
code construct's reason to be there is that you can deal
better with the
complexity you're facing. If applying a construct doesn't
make the complexity
you're facing less complex, don't apply it.

> After you've done this, you have a set of classes, and
you actually have two
> choices.
>
> 1) you can now forget about all these classes, and
design a db schema based
> model for the domain, as if you are doing the DB
oriented modelling. After
> this you generate OO reflections of your DB model by
reverse enginering this
> schema, and now you have two sets of "domain
classes". One set is build on
> OO concepts, and the other one is mappings to OO
concepts from DB concepts.
> A tool oriented summary is like this:
>
> [Classes generated from UML] <------->[connector
> layer/service/class]<------------> [classes
generated from DB
> schema]<----------->[ORM
services]<--------->[DB]
> Here, there is a possibility of overlapping, like very
similar classes in
> both UML generated set and ORM generated set. But when
inheritence and other
> OO concepts are used heavily in OO based set, the
distinction is usually
> clear. Here, ORM based classes become kinda DTOs for
DAOs, where DAO pattern
> is encapsulated in connector layer.
> Do you think the architecture above is overkill?

        Yes

> Do you think that instead
> of modelling DB by looking at the domain, we can model
it as using the class
> designs as inputs? I am trying to see if I can justify
the appoarch above, I
> guess the only way to do that is to give it a try in a
moderate sized
> project, which I have at hand at the moment, but still
your opinions would
> be quite valuable.

        I'll give you the following advice, even if it
sounds weird. Design an
abstract entity model first. Just try it, use Object role
modelling or NIAM,
with inheritance etc.. Then convert it to both classes and
tables.

        How you physically implement these types, i.e. if
the 'Customer' class
inherits from a central base class, or from nothing (because
for example POCO
is the norm), that's not important, as long as 'customer'
represents
'customer', and not something that's only true in the
reality of the class
model, because you then miss something essential: the
conversion rules how to
come from CustomerX to customer and vice versa.

                FB

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

On Wed, Jul 23, 2008 at 7:02 AM, Seref Arikan
<serefarikankurumsalteknoloji.com> wrote:
> [Classes generated from UML] <------->[connector
> layer/service/class]<------------> [classes
generated from DB
> schema]<----------->[ORM
services]<--------->[DB]

With the Repository pattern, you could do as follow:

[Business
classes]<--->[Facade/service]<--->[Generic
DAL]<--->[DB]

The generic DAL will need some mapping between OO classes
and DB
schema, and this is where code generation come in handy
because doing
that mapping by hand is tedious and error prone.

-- 
Sébastien
www.sebastienlorion.com

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Hi Frans, comments are inline.


       and those are?  Isn't the
code generated also OO? Mind you: your
client doesn't give a **** about how you wrote the software,
he just wants
software that solves his problems. So if you thought about a
fancy
architecture with a lot of services and all the latest
buzzwords, it's not
important. What's important is that what's used makes things
easier and
better

to understand what's going on, i.o.w.: no surprises, no
traps.

Let me just say that I do not feel comfortable about
injecting business
logic related code into generated ORM classes. Even if the
generated code is
OO (which is true in your product's case I am not
comforable with adding
behavior for purposes other than persistence to that code.
Since behaviour
can not exist on its own in an OO context, this implicitly
forces me to
define domain objects as another set of classes. This leads
to a situation
where I have two sets of classes that represent the same
domain, but have
different responsibilities. One set covers business
requirements, the other
covers persistence. I know that they can be combined, but It
feels cleaner
this way. You are absolutely right about the client. They
don't give ****
about the background work, and the whole point of this
dicsussion, which has
been quite satisfactory for me, is about making MY work
easier  The
missing benefits from OO are motly about being free about
the design domain
classes. Generated code comes in a particular structure,
which you can
contribute/extend, but it has an existing inheritence
structure anyways. the
app I've mentioned before uses state pattern for example,
and injecting this
into OO generated code is not as natural as designing it
from scratch by
looking at requirements. One more thing, keeping ORM
generated classes
without business logic has the advantage of having an easily
serializable
layer, which works great for me.

       I'll give you the following advice, even if it sounds
weird. Design
an
abstract entity model first. Just try it, use Object role
modelling or NIAM,
with inheritance etc.. Then convert it to both classes and
tables.

      Ok, this is a n advice which I'll put to test, and I'm
glad to hear
it. This overall discussion has been great actually!

Cheers

Seref

               FB

===================================
This list is hosted by DevelopMentor(R)  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com


===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

On Thu, Jul 24, 2008 at 2:54 AM, Seref Arikan
<serefarikankurumsalteknoloji.com> wrote:
> Let me just say that I do not feel comfortable about
injecting business
> logic related code into generated ORM classes. Even if
the generated code is
> OO (which is true in your product's case I am not
comforable with adding
> behavior for purposes other than persistence to that
code. Since behaviour
> can not exist on its own in an OO context, this
implicitly forces me to
> define domain objects as another set of classes. This
leads to a situation
> where I have two sets of classes that represent the
same domain, but have
> different responsibilities. One set covers business
requirements, the other
> covers persistence. I know that they can be combined,
but It feels cleaner
> this way.


Before partial classes, adding custom business logic to
generated
classes would have been out of the question, but have you
considered
their use in your scenario now that they are available ?

Sébastien

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Hi Sebastien,

No I have not thought about that before, and it is an
interesting idea
indeed! I've been happy about some new features of the
language, but I've
been kinda conservative about a few of them, and partial
classes has been
one . I guess I'm getting old 

Cheers

Seref

On Thu, Jul 24, 2008 at 10:35 PM, Sébastien Lorion <
sebastien.loriongmail.com> wrote:

> On Thu, Jul 24, 2008 at 2:54 AM, Seref Arikan
> <serefarikankurumsalteknoloji.com> wrote:
> > Let me just say that I do not feel comfortable
about injecting business
> > logic related code into generated ORM classes.
Even if the generated code
> is
> > OO (which is true in your product's case I am not
comforable with
> adding
> > behavior for purposes other than persistence to
that code. Since
> behaviour
> > can not exist on its own in an OO context, this
implicitly forces me to
> > define domain objects as another set of classes.
This leads to a
> situation
> > where I have two sets of classes that represent
the same domain, but have
> > different responsibilities. One set covers
business requirements, the
> other
> > covers persistence. I know that they can be
combined, but It feels
> cleaner
> > this way.
>
>
> Before partial classes, adding custom business logic to
generated
> classes would have been out of the question, but have
you considered
> their use in your scenario now that they are available
?
>
> Sébastien
>
> ===================================
> This list is hosted by DevelopMentor(R)  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com

>

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

> No I have not thought about that before, and it is an
interesting idea
> indeed! I've been happy about some new features of the
language, but I've
> been kinda conservative about a few of them, and
partial classes has been
> one . I guess I'm getting old 

        heh 

        I think it's not that weird to avoid partial classes
when you can.
AFter all, it's not really increasing maintainability that
much, as code is
scattered over multiple files. But it's a big step forward
compared to the
in-file code regions which were 'safe havens' for custom
code in generated
code. 

        Code generation is a topic that's being researched a
lot. There are a
lot of neat ideas but not a lot of these flow down to the
developer's toolbox.
Lets hope that changes in the coming year(s) ;)

                FB 
	

> 
> Cheers
> 
> Seref
> 
> On Thu, Jul 24, 2008 at 10:35 PM, Sébastien Lorion
<
> sebastien.loriongmail.com> wrote:
> 
> > On Thu, Jul 24, 2008 at 2:54 AM, Seref Arikan
> > <serefarikankurumsalteknoloji.com>
wrote:
> > > Let me just say that I do not feel
comfortable about injecting business
> > > logic related code into generated ORM
classes. Even if the generated
code
> > is
> > > OO (which is true in your product's case I am not
comforable with
> > adding
> > > behavior for purposes other than persistence
to that code. Since
> > behaviour
> > > can not exist on its own in an OO context,
this implicitly forces me to
> > > define domain objects as another set of
classes. This leads to a
> > situation
> > > where I have two sets of classes that
represent the same domain, but
have
> > > different responsibilities. One set covers
business requirements, the
> > other
> > > covers persistence. I know that they can be
combined, but It feels
> > cleaner
> > > this way.
> >
> >
> > Before partial classes, adding custom business
logic to generated
> > classes would have been out of the question, but
have you considered
> > their use in your scenario now that they are
available ?
> >
> > Sébastien
> >
> > ===================================
> > This list is hosted by DevelopMentor(R)  http://www.develop.com
> >
> > View archives and manage your subscription(s) at
> > http://discuss.develop.com

> >
> 
> ===================================
> This list is hosted by DevelopMentor®  http://www.develop.com
> 
> View archives and manage your subscription(s) at http://discuss.develop.com


===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

> Before partial classes, adding custom business logic to
generated
> classes would have been out of the question, but have
you considered
> their use in your scenario now that they are available
?
> 
> Sébastien

No it wouldn't have.  We use NetTiers at Chase, and while
maybe not ideal,
it works well, and we add custom logic to generated derived
classes.  This
is legacy from before we had generated partial classes.

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

> No it wouldn't have.  We use NetTiers at Chase, and
while maybe not ideal,
> it works well, and we add custom logic to generated
derived classes.

I've been using a similar setup (except using CSLA, not
NetTiers) for a
while now, also using base + derived classes.

> This is legacy from before we had generated partial
classes.

I'm a little bit surprised that everybody seems to be saying
that partial
classes > inheritance.  I'm not saying that inheritance
is a perfect fit for
the whole "reverse engineer DB into a persistence
layer" scenario, but I
prefer to at least have some buffer between the generated
code and the
business logic.  There are certain things in the generated
code that you
should see / touch, and inheritance helps ensure that you do
not.  In cases
where you do need to do muck around with the plumbing, the
override keyword
at least helps indicate that you have done so.

What good arguments pro-partial classes am I missing?

-- Daniel.

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com