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

What it sounds like to me is that you want to utilize agile
software
development techniques.  One tenet of this is to keep
coupling very low.
This follows the basic OO principle or single responsibility
(SRP).  Said
in another way: a class should have only one reason to
change.  If you're
modeling a domain object and the implementation of the class
must change
when the DB changes, you're violating SRP and have
tight-coupling.  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.

The drawback of generating types from DB schema is your are
effectively
coupling modeled types to the DB.  Do all changes to DB
schema ripple
throughout the system?  Of course not; but when they do you
can't make
changes in a timely fashion.  Using OO principles and
implementing the
Repository pattern means most changes to the DB ripple only
into the
Repository implementations.

I honestly don't think you can be agile in the long run with
round-
tripping code from DB schema.  It's one thing to start with
DB schema,
generate domain classes from them then they live on their
own.  But,
coupling all the domain types in your business layer
directly to DB schema
(by way of generating code from schema) means, at least
some, changes to
the DB have to much of an effect on too much of the system
to make it
easily maintainable.

Do some projects work this way?  It depends on what you call
"works".  I
find in situations like that there's lots of push-back from
the devs when
the customer wants changes.  The devs know the changes will
ripple through
the entire system, be difficult to do, time-consuming,
affect quality,
etc.  If they do make the change, quality usually suffers
and the customer
isn't happy.  If they don't make the change then the
customer doesn't have
what they want, and they're not happy.  So, not being agile
can affect
capability.

On Wed, 23 Jul 2008 14:02:13 +0300, Seref Arikan
<serefarikanKURUMSALTEKNOLOJI.COM> wrote:

>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/archive/2006/08/2
3/Essay_3A00_-The-
Database-Mode
>> l-is-the-Domain-
Model.aspx<http://weblogs.asp.net/fbouma/archive/2006/08/23/Es
say_3A00_-
The-Database-Model-is-the-Domain-Model.aspx>
>>        and I rehashed it abit in different wording
here:
>>
>> http://weblogs.asp.net/fbouma/archive/2008/0
5/19/why-use-the-entity-
framework-
>> yeah-why-
exactly.aspx<http://weblogs.asp.net/fbouma/archive/2008/05/19/wh
y-use-the-
entity-framework-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.

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

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

I wonder if the SQL Server team uses OO or DB concepts when
coding? Discuss.

--
James Thurber  - "Women are wiser than men because they
know less and
understand more."

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

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

Whether you use Repository or Active Record, when a new
*mandatory*
field is added to a table, that change usually ripples
through the
whole project, from DAL to GUI. Removing a field or changing
its type
would have the same impact.

>From my own experience, the only change with an effect
that can be
limited, to the DAL or even only the DB, is adding a non
mandatory
field or one where a default value makes sense.

So talking about tight/loose coupling in the context of ORM
has some
inherent inescapable limitations.

Sébastien

On Wed, Jul 23, 2008 at 12:04 PM, Peter Ritchie
<advanced.dotnet.discuss.develop.competerritchie.com> wrote:
> What it sounds like to me is that you want to utilize
agile software
> development techniques.  One tenet of this is to keep
coupling very low.
> This follows the basic OO principle or single
responsibility (SRP).  Said
> in another way: a class should have only one reason to
change.  If you're
> modeling a domain object and the implementation of the
class must change
> when the DB changes, you're violating SRP and have
tight-coupling.  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.
>
> The drawback of generating types from DB schema is your
are effectively
> coupling modeled types to the DB.  Do all changes to DB
schema ripple
> throughout the system?  Of course not; but when they do
you can't make
> changes in a timely fashion.  Using OO principles and
implementing the
> Repository pattern means most changes to the DB ripple
only into the
> Repository implementations.
>
> I honestly don't think you can be agile in the long run
with round-
> tripping code from DB schema.  It's one thing to start
with DB schema,
> generate domain classes from them then they live on
their own.  But,
> coupling all the domain types in your business layer
directly to DB schema
> (by way of generating code from schema) means, at least
some, changes to
> the DB have to much of an effect on too much of the
system to make it
> easily maintainable.
>
> Do some projects work this way?  It depends on what you
call "works".  I
> find in situations like that there's lots of push-back
from the devs when
> the customer wants changes.  The devs know the changes
will ripple through
> the entire system, be difficult to do, time-consuming,
affect quality,
> etc.  If they do make the change, quality usually
suffers and the customer
> isn't happy.  If they don't make the change then the
customer doesn't have
> what they want, and they're not happy.  So, not being
agile can affect
> capability.
>
> On Wed, 23 Jul 2008 14:02:13 +0300, Seref Arikan
> <serefarikanKURUMSALTEKNOLOJI.COM> wrote:
>
>>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/archive/2006/08/2
3/Essay_3A00_-The-
> Database-Mode
>>> l-is-the-Domain-
> Model.aspx<http://weblogs.asp.net/fbouma/archive/2006/08/23/Es
say_3A00_-
> The-Database-Model-is-the-Domain-Model.aspx>
>>>        and I rehashed it abit in different
wording here:
>>>
>>> http://weblogs.asp.net/fbouma/archive/2008/0
5/19/why-use-the-entity-
> framework-
>>> yeah-why-
> exactly.aspx<http://weblogs.asp.net/fbouma/archive/2008/05/19/wh
y-use-the-
> entity-framework-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.
>
> ===================================
> This list is hosted by DevelopMentor(R)  http://www.develop.com
>
> View archives and manage your subscription(s) at http://discuss.develop.com

>



-- 
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

> Thank you Frans!  Even as a noob in the ORM sphere, I
have always felt this
> way, and in fact wanted interject into this discussion
before you said this.
> In my years as a designer/developer, I have very, very
seldom ever seen
> changes to the DB entity that do not require changes to
the class.  The
> changes are business driven, and when the client wants
a change to their
> Person, it always requires a change to the class and
the entity, because the
> Person they both represent changes.

Could this be because you are/were working in a data centric
world? I
regularly see changes in database structure that do not
represent
changes in my domain. An example of this might be selective
denormalization for optimization on a small system or the
pulling out
of something that was columns into a new joined table.

Cheers,

Greg

On Thu, Jul 24, 2008 at 2:22 AM, Brady Kelly <bradychasesoftware.co.za> wrote:
> Frans:
>
>>         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.
>>
>>         So the coupling isn't between table and
class, the coupling is
>> between
>> abstract entity E and class, and also between E and
table, simply
>> because E is
>> the source and both class and table are projections
of E's definition.
>> The
>> class and the table aren't standalone items which
fell out of the sky.
>
> Thank you Frans!  Even as a noob in the ORM sphere, I
have always felt this
> way, and in fact wanted interject into this discussion
before you said this.
> In my years as a designer/developer, I have very, very
seldom ever seen
> changes to the DB entity that do not require changes to
the class.  The
> changes are business driven, and when the client wants
a change to their
> Person, it always requires a change to the class and
the entity, because the
> Person they both represent changes.
>
> ===================================
> This list is hosted by DevelopMentor(R)  http://www.develop.com
>
> View archives and manage your subscription(s) at http://discuss.develop.com

>



--
It is the mark of an educated mind to be able to entertain a
thought
without accepting it.

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

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

> Could this be because you are/were working in a data
centric world? I
> regularly see changes in database structure that do not
represent
> changes in my domain. An example of this might be
selective
> denormalization for optimization on a small system or
the pulling out
> of something that was columns into a new joined table.
>
> Cheers,
>
> Greg

Maybe with less coupling I would see more changes like that,
but now that I
consider it, coupling is the reason I don't see these
changes.  They are
considered indulgent, as they would require 'unnecessary'
code changes.

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

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

> Maybe with less coupling I would see more changes like
that, but now that I
> consider it, coupling is the reason I don't see these
changes.  They are
> considered indulgent, as they would require
'unnecessary' code changes.
>

To clarify a bit...

Down a DDD path this coupling does not exist (you embrace
the
impedance mismatch). This allows for a lot more flexibility
in
creating both models in the ways that you find optimal for
each
without a whole lot of concern for the other. Often as
systems run you
find changes to one of the models that would make it more
effective,
these changes may or may not affect the other model.

Others have been doing this on the db side of things by
providing an
"API" through sprocs for a long time which can be
a good comparison.
If your db is only accessed through sprocs how many database
changes
do you see without code changes?

Cheers,

Greg

On Thu, Jul 24, 2008 at 8:55 AM, Brady Kelly <bradychasesoftware.co.za> wrote:
>> Could this be because you are/were working in a
data centric world? I
>> regularly see changes in database structure that do
not represent
>> changes in my domain. An example of this might be
selective
>> denormalization for optimization on a small system
or the pulling out
>> of something that was columns into a new joined
table.
>>
>> Cheers,
>>
>> Greg
>
> Maybe with less coupling I would see more changes like
that, but now that I
> consider it, coupling is the reason I don't see these
changes.  They are
> considered indulgent, as they would require
'unnecessary' code changes.
>
> ===================================
> This list is hosted by DevelopMentor(R)  http://www.develop.com
It is the mark of an educated mind to be able to entertain a
thought
without accepting it.


down a DDD path this coupling does not exist.
> Vieummw archives and manage your subscription(s) at http://discuss.develop.com

>



--
It is the mark of an educated mind to be able to entertain a
thought
without accepting it.

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

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

> > Thank you Frans!  Even as a noob in the ORM
sphere, I have always felt
this
> > way, and in fact wanted interject into this
discussion before you said
this.
> > In my years as a designer/developer, I have very,
very seldom ever seen
> > changes to the DB entity that do not require
changes to the class.  The
> > changes are business driven, and when the client
wants a change to their
> > Person, it always requires a change to the class
and the entity, because
the
> > Person they both represent changes.
>
> Could this be because you are/were working in a data
centric world?

        What's 'data centric' ?

> I regularly see changes in database structure that do
not represent
> changes in my domain. An example of this might be
selective
> denormalization for optimization on a small system or
the pulling out
> of something that was columns into a new joined table.

        Ah, and denormalization side effects like multiple
rows with the same
data of the same entity aren't a problem in your code,
because that's
transparently solved? I don't think so.

                FB

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

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