> It's my experience that layered enterpise applications tend
> to be biased to the database. Despite some really good O/R
> mapping tools (and due to some poor ones), I see often see
> designs in which relational data is mapped to an object model
> that has a very heavy relational smell to it, i.e. through
> all layers I can clearly see the database scheme. For some
> reason, for a lot of developers this approach is quite
> tempting. I think that in an environment where
> database-related functionality is hidden as much as possible,
> bad designs like these show up less frequently.
Whoa, who's the one who doesn't understand what system design is
all about? :-S
A relational model in a database is not something cooked up over
a dinnertable, it's the result (!) of an abstract model like a NIAM/ORM
model. In there you define entities, like customer and order, and define
relationships between them. These relationships aren't there just
because some moron thinks they should be there, they are there because
these entities have these relationships. This means that EACH instance
of these entities have these relationships.
Now, tell me, why oh why shouldn't this be showing in your
application? Because someone (who?) defined that as 'bad' design (your
words!)?
If I pull a customer out of the database and want to work with
that customer entity, I'd like to be able to grab the orders of that
customer without a lot of hassle: a system which is not filled till the
teeth with relational logic based on the relational model (which is the
core foundation of your complete application! Read more Yourdon) will
make it only harder to get these orders.
Or worse: when you want to grab all customers who bought a given
product. How to filter out these customers? How are YOU going to specify
the relationships this filter has to be based on (customer - order -
orderrow - product) without relational logic?
Don't you see what you are suggesting is totally the opposite of
what's correct? Isn't that the reason why you see so much relational
model-oriented systems, because the core of the application is simply
manipulating data (as is with the far majority of applications)?
> I really have to admit that I haven't spend a lot of time
> thinking all this stuff over. So maybe it was a bad idea to
> bring it into this discussion.
It's not bad to bring up a discussion, it's IMHO not that wise
to start a discussion with buzzword mumbo jumbo which are not used in
the correct context :)
> And maybe, the subject should not have been 'Transparent Persistence',
but something like
> 'Hiding persisitence-related functionality as much as
> possible'. But I just wanted to see what kind of ideas you
> guys have about these matters. (I did *not* want to invoke a
> flame-like outburst from Thomas, anyway. And I've no
> intension to reply on such a post.)
In LLBLGen Pro I offer both: I called them SelfServicing and
Adapter. Fetching an entity:
// fetch CHOPS, selfservicing.
CustomerEntity customer = new CustomerEntity("CHOPS");
its called selfservicing, because it 'serves itself', thus it doesn't
need external objects to work.
Adapter requires this code to do the same:
CustomerEntity customer = new CustomerEntity("CHOPS");
DataAccessAdapter adapter = new DataAccessAdapter();
adapter.FetchEntity(customer);
Self servicing, save: (not yet recursive, will be released in 1 week)
customer.Save();
Adapter, save: (recursively, thus all internal referenced objects, if
dirty, will be saved as well.
DataAccessAdapter adapter = new DataAccessAdapter();
adapter.SaveEntity(customer);
The joy of selfservicing is also a limitation: in an asp.net
page I can also execute the Save() method, however because the
DataAccessAdapter class is located in another assembly as the O/R
classes and the entity classes, I can't save it using the Adapter model.
Other O/R mapper vendors use similar approaches to Adapter, by
using a broker or context. Advantages are that you have lightweight
entity objects without persistence informatoin or logic, disadvantage is
that you need that external object each time you want to do things.
With an external object, for a GUI and also for a BL tier which
consumes the DAL tier, it really isn't showing where the objects are
coming from, nor is it important: it requires lower tiers to provide the
objects and work with the data. However in lower tiers, where entity
objects have to be instantiated to get things done, you have MORE
transparency with the selfservicing approach than with the adapter
approach, so there the things are totally different.
For some people, persistence logic is a behaviour component of
an entity. These people want that logic as part of the behaviour of the
entity itself, thus 'Save()' is a method of the entity. Other people see
persistence logic as a service which can be applied to objects. FOr
these people having a Save() method in an entity is weird, you should
call a Save() method and pass in an entity.
Both ideas have pro/cons, and because I wrote both I can say
this :), and I don't think anyone of the two is a bad approach over the
other. Selfservicing is easier to use, but as I said, somewhat limited
to the semantical aspects of what people want in a tier. Adapter is less
easier to use, but more applicable in various tier setups.
> The next couple of months, I'll be busy with other stuff than
> layerd enterprise app's, so I don't think these thoughts will
> be worked out in a detail yet. But maybe I'll bring in some
> more concrete insights one day. ;)
Read more articles written by prof. T.A. Halpin on www.orm.net,
read Dr. Peter Chen's article "The entity-relationship model - toward a
unified view of data", ACM Transactions on database systems vol.1 no.1,
march 1976, page 9-36", (download here:
http://bit.csc.lsu.edu/~chen/pdf/erd.pdf ) to read about what an entity
really is. Read also more books written by E. Yourdon, and make
combinations between what Halpin has created, what Chen has defined and
what Yourdon has described. I think it will then be hard for you to say
what you said about relational-model based layered systems and
transparent persistence. :)
FB
--------------------------------------------------------------------
Get LLBLGen Pro, the new O/R mapper for .NET: http://www.llblgen.com
My .NET Blog : http://weblogs.asp.net/FBouma
--------------------------------------------------------------------
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
Some .NET courses you may be interested in:
NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnetls
View archives and manage your subscription(s) at http://discuss.develop.com
