Re: The effects of ORM in architecture and domain driven design

I don't consider it harsh; I think that at some level we're
actually
agreeing and that you've misunderstood what I've said.  Read
on...

On Wed, 23 Jul 2008 19:10:46 +0200, Frans Bouma
<perseus3XS4ALL.NL> wrote:

<snip>
>        Of course there's coupling, they represent the
same thing!

Yes, they represent the same things; but coupling to their
implementation
is bad.

>        So you have this:
>Abstract entity E
>        -> is represented in the relational schema by
1-n tables/views
>        -> is represented in the class model by 1-m
classes.

>        So the point isn't 'when the db changes a class
has to change and
oh
>boy this implies coupling and therefore it's bad'. The
point is: E
changes! So
>E's changes should be reflected in its physical
representations: both in
the
>DB and in the class model. How, that's up to the context
of how the
entity is
>represented. Perhaps a change has no effect in code but
does in the DB,
or has
>an effect in code but no effect in the DB.

It depends on the type of coupling whether changes ripple
through the
system.  An entity directly coupled to the db schema through
some
nebulous "code generator" means every change in db
schema will likely mean
a change in the entity.  With mapping layer (either an OR/M,
and/or
application-specific mapping, and/or Repository pattern
implementation,
etc.), you decouple the implementations (yes, they're still
coupled; but
more indirectly).  And make it less likely changes will
ripple throughout
the system.

I should have been more clear in what I blanketly described
as "changes".
I mean one-sided changes.  If you're changing the abstract
entity, that
change is realized as changes to the entity type AND the DB
(and the
infrastructure in between, likely)--which isn't a one-sided
change.  If
this nebulous "code gen" creates a one-to-one
mapping from table to type,
or from column type to property type you're very tightly
coupled.

>        That's also why O/R mapping theory even works:
because class and
table
>(or tables) represent the same thing, you can pass data
in class instance
to
>table and vice versa. If class and table wouldn't
represent the same
thing,
>don't give meaning to the data that the data is an
instance of the same
>entity, you can't use an O/R mapper at all, because
you're passing data
back
>and forth but the data suddenly gets completely
different meaning, or
better:
>it has meaning in a table row, but has no meaning in the
class instance,
or
>vice versa.

I didn't intend to imply that OR/M isn't sufficient enough
to implement
this decoupling.
>
>        One of the critical points about using a
database is that the
tuples
>of data inside the database are just bits and represent
something as soon
as
>meaning is given to them, e.g. they're seen as entity
instances in a table
>(rows)

No, data in the database is a specific implementation of a
representation
of concepts.  That implementation gives it meaning, in that
context;
meaning that may or may not need to be translated into
another context
Implementation that can be coupled to.

<snip>

>
>> Can software that works be written this way?  Of
course (so, yes, this
isn't
>> really about capability, its about responsiveness
to change).  But, it
>> means changes to one aspect of the system ripple
through the rest of the
>> system.  This makes it difficult, costly, and
time-consuming to make
>> changes.

>        Of course not. Only people who have no clue what
the entity class
and
>the table in the schema represent suffer from this.

And this is what I'm talking about.  If you're using an OR/M
and mapping
classes to tables, then I'm simply reinforcing what you're
doing, i.e.
you're decoupling database implementation from business
layer entity
implementation.  I don't see how you can do that when
classes are
generated from DB schema...

<snip>

>        Not true, any change to an entity could ripple
through in your
code,
>using repositories or not, after all: you consume the
result objects a
>repository produces in code outside the repository.
Don't think that that
code
>is safe from a change in an entity, it's not. Even
worse: if you think
you can
>avoid it, you run the risk that the code you wrote LOOKS
like it contains
data
>which are instances of a given entity, but in practise
that's not the
case.
>

Every change to your abstract entity must ripple through the
system; but
you're changing the abstract concept, not the implementation
(yet).  When
DB drives the whole process it always influences/leaks-into
implementation
of the rest of the system.  People should be thinking about
the behaviour
of the abstract entity and that should both drive the
business layer
implementation and the DB schema.  That way the DB
representation can do
what it needs to do for that particular DB or scenario more
independently
from the rest of the system.  If that means introducing a
new table to
implement that, so be it; but the existence of that new
table isn't
reflected by anything in the business layer.  How do you
deal with that
scenario if your entity code is a generated representation
of the DB
Schema?  By default generating code from DB schema is
one-type-per-table,
and isn't detailed enough to define behaviour, making it
really hard to
not to influence your domain model (both abstract and
business layer
implementation of it).


>        Though you again seem to miss the point: a DB
schema change
doesn't
>fall out of the sky: an abstract entity definition has
changed and it has
had
>an effect on how the relational model representation of
this entity: some
>changes are necessary. To be able to work with the
changed entity (which
is
>the abstract definition) in your code, you too have to
check if the
>representation of the entity (in one or more classes)
needs a change.
That's
>not a given. If it does, you have to make the change
there too. That's not
>strange, as both represent the same entity, and THAT
entity got changed.

You've missed my point, see above, I should have clarified
changes
better.  The DB will change over time independently of the
domain model.
As load increase the admin might find that the schema needs
to change to
accommodate performance, space, etc.   Changing the abstract
entity is
different; that will drive changes to both the business
layer and the DB.
And vice versa, changes to the business layer implementation
of an entity
(when not changing the abstract entity) is an independent
change.  But,
how do you manage that in a strictly
business-layer-entity-generated-from-
DB-schema environment?

<snip>

As for the rest of your rant (nothing personal), see my
clarifications
on "changes" and "generating code from
schema".

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

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