First off, thanks for the excellent description (a different post) of your point of view of how and why to model association tables. I have a better understanding of where you're coming from. A good design shouldn't preclude an object representation of the relationships themselves. Of course good OO design doesn't dictate you shouldn't do that, but like composition, somehow it doesn't seem to make the 101, 102 class syllabus very often.
> Legacy stuff is a problem indeed. Bad designed relational > models, databases with tables without a PK but with a UC :D. If these > bad designs are included in the code, you have two times the trouble. > > I doubt however if you can make this misery any less bad for > your project when you're including a layer which allows you to create a > complete different object model with apparently no logical connection > (exxagerated) with the database model. You then run the risk the OO code > is also unmaintainable in the end because yuo need a lot of in-depth > knowledge where which data is stored, why that FK constraint is throwing > an exception when you want to write a hierarchy to the database etc., > when you want to update that code after, say, 6 months of not working on > it. :) In my experience, legacy is the key problem, not a sometimes problem. If you do project work, you often have the luxury of starting from scratch in both application and database design. That's lucky. Between old data, reports that access data directly, enterprise integration projects, older versions of the existing application, older applications you are rewriting needing to exist during the transition, and the sheer amount of time it can take to write applications while your business keeps on ticking, I find that the database design most often operates under a different timeline than any given application design. You have to deal with it. The software way of dealing with it is to build another indirection and it works pretty well. Now, in your situation where you want to add great value to your customers and offer repeated reliable generation of database persistence, having the database change underneath must represent a tremendous challenge. But for many of us, it's a reality we simply have to deal with, so having another layer of indirection, which can be accomplished by queries, views, stored procedures etc, that offers the applications view of the database, is a very useful thing. In my DAL, I take it one step further in that all my queries are accessed by name, a name that can change independently from the name used by the database if it's a stored proc. The optimal database design always has a context under which the assumptions are made. It very well may not be the context of the application you are currently working on. ===== Philip "There's a difference between righteous anger and just being crabby" Barbara http://blogs.xcskiwinn.org/panmanphil =================================== 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
