Frans, > Whoa, who's the one who doesn't understand what > system design is all about? :-S
Ouch. That hurts. It really does. But---fortunately---you misunderstood me. ;) Modeling is hard. But let's assume that we've managed to do a good job here and that we came up with a very good model for a specific domain. Furthermore, let's assume that we've used Halpin's ORM, with which I'm quite familiar actually ;). >From this model, we come up with a) an object-model design for our application layer, and b) a relational-database schema for our data layer. These are really two distict tasks! Consider for example how many-to-many relationships are modelled in database schemas: we need auxilliary tables there. Well, there will be no such things as auxilliary classes in our application-layer object model. So, our basic model is still good, but different layers need different incarnations of it. No problem so far: nothing but 'good design'. Over to 'bad design' ... And this is something I've encounterd in real life many times now. First of all, it seems tempting to forget about coming up with a good basic model and just write out a database schema. I guess I don't need to tell you what's wrong about that. :) But, even if we could convice our design team to use the ORM model we've carefully composed, danger is just around the corner. I've worked with teams that spent a lot of time in designing the database and then rushed forward and wrote application-layer class definitions that were just one-on-one translations of the database tables. So, there were, for instance, auxilliary classes showing up to model many-to-many relationships! This is what I mean by 'being able to seeing the database through all layers'. This is what I consider 'bad design'. I hope you agree with me about this. Regards, Stefan > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Frans Bouma > Sent: Friday, February 13, 2004 9:02 PM > To: Moderated discussion of advanced .NET topics. > Subject: RE: [ADVANCED-DOTNET] Transparent Persistence > > > 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
