> > [...] After all, the m:n link table IS an entity, by definition of
the
> > relational model. [...]
>
> Not just an entity, however. ER modelling would recognize it
> as a *weak* entity.
True, however it's not ignored. It's a little nittpicking, but I
wanted to illustrate the general purpose of this intermediate table and
what is happening if hte datamodel changes and if you really want to
sideeffects in your code.
> The linking table in the relational
> database typically will not be biased towards either of the
> two linked tables. In the application-level object model the
> resulting collection often is biased towards one of the
> linked classes. Order rows, for instance, will be owned by an order.
This is a semantical choice of course and also a problem
sometimes: order has fk's with customer and employee. Do you store a new
order in Employee.Orders or Customer.Orders? Storing it in one requires
that the fk of the other is set to a value, otherwise the insert will
fail. It's natural (in this case) to add the Order to Customer.Orders,
however where is it stated that the employeeID FK in order has to be set
as well?
It boils down to the fact that a developer is better of with a
relational graph on his desk of the entities (f.e. an ERwin printout or
the NIAM model) which entities are related to which entity and on which
condition (mandatory or not).
I got the feeling you mixed a few things up a little though. Let
me explain. When you opt for a 'manager' solution, that is you have
classes like 'OrderManager' and the like (more the SOA approach) a GUI
tier simply uses these classes to get things done so it requests data
from these classes (probably a couple) to get a form filled and calls a
few to get changes propagated down or checked. For the GUI it's a
complete black box how the relations between the data are, it just calls
methods in a tier below it and gets data in return or calls a method and
gets stuff saved, who knows in how many tables.
So it is then debatable if the GUI should know of the relational
model and for example should set Order.EmployeeID to a value because it
is mandatory, should add the order to Customer.Orders because it belongs
there, or should it simply call a method, pass the Order, the customer
and the Employee and nothing further? Wasn't this the issue you referred
to in your remark about layered design related to bad/good design?
FB
>
> Regards,
>
> Stefan
>
> ===================================
> This list is hosted by DevelopMentor(r) 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
