Frans: > So the point isn't 'when the db changes a class has to change > and oh > boy this implies coupling and therefore it's bad'. The point is: E > changes! So > E's changes should be reflected in its physical representations: both > in the > DB and in the class model. How, that's up to the context of how the > entity is > represented. Perhaps a change has no effect in code but does in the DB, > or has > an effect in code but no effect in the DB. > > So the coupling isn't between table and class, the coupling is > between > abstract entity E and class, and also between E and table, simply > because E is > the source and both class and table are projections of E's definition. > The > class and the table aren't standalone items which fell out of the sky.
Thank you Frans! Even as a noob in the ORM sphere, I have always felt this way, and in fact wanted interject into this discussion before you said this. In my years as a designer/developer, I have very, very seldom ever seen changes to the DB entity that do not require changes to the class. The changes are business driven, and when the client wants a change to their Person, it always requires a change to the class and the entity, because the Person they both represent changes. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
