> <FB> Now, the manager thinks he needs to know when
> each employee
> started at which department. To model this correctly, you
> have to objectify the department-employee relationship into a
> relation, and add a non-pk, mandatory attribute 'StartDate'.
>
> Now, go back to the codesnippet I just posted. It
> definitely will not work, you need to add StartDate as well,
> as it is mandatory.
> You also can't add the employee directly to Employees in the
> department object, as it is related via a 3rd entity, so to
> reach the department from an enmployee, the developer has to
> do something like:
> </FB>
>
> If someone with any decency did this to a database, they
> first would have to establish what mandatory StartDate to
> assign to all existing rows in the database, then and ONLY
> then could they define the column as NOT NULL. The EXACT
> same logic could be codified in support of the OLD interface.
no, because how would this save a correct value in the row:
Department.Emplyees.Add(newEmployee);
Department.Save(); // or equivalent
It's the topic the example tries to illustrate, not hte example
itself that is important. If an m:n relationship has to be objectified,
it has to be altered, and code currently using the 'hidden entity'
approach is out of luck and has to be changed. Not only is that a pain,
it's also not logical: the developer working with the NEW interfaces has
to KNOW that StartDate is mandatory and that the hidden approach is not
possible.
> Now suppose that this code hasn't been released, so there are
> no existing rows in the database. Then the project manager
> decides if supporting the old interface with the necessary
> cost of establishing the defaulting rules is more or less
> costly than revisiting the _also unshipped_ client code.
> Whatever discussion is best for the company can be handled with ease.
> The problem with most of these discussions is that it
> completely ignore the revisioning of interfaces, because that
> is a hard problem to solve generically.
True, it's a problem but IMHO not that big as the inconsistency
it otherwise would bring to the table. Would the hidden entity simply
have been used, it would not have been a problem at all.
FB
===================================
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
