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/23/Essay_3A00_-The-Database-Mode
l-is-the-Domain-Model.aspx
and I rehashed it abit in different wording here:
http://weblogs.asp.net/fbouma/archive/2008/05/19/why-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.
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® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
