" 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. "
Come on, Frans. You know, at your level of experience, that the physical model of a
database is
often very different from the logical one. He's saying that it's sometimes the case
that someone
builds a database first and the application after, and that the data structures often
then mirror
the table structure. He's right! I've seen this very thing in practice. Think of a
structure
with lots of mapping tables, and a special object created for every one of those
links, because
some developer thought it was a good idea to create class AToBMap to mirror table
a_b_map. Yet a
mapping table is usually the simplest and best way, and often the only way, to
represent a
many-to-many relationship in many RDBMSes.
Not only that, but even without normalization, denormalization, bad design in the
database (ever
have to write an application that used an existing bad structure?), etc. it is often
natural to
implement many complicated things differently in database and object form. Things
aren't always
as simple as we'd like to be.
Jeff
--- Frans Bouma <[EMAIL PROTECTED]> wrote:
> > 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
===================================
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
