If you have not read it already, I would like to suggest Eric Evans's book Domain-Driven Design. It actually deals with your domain! I would also suggest you look at the recent posts on [EMAIL PROTECTED] that have covered very similar issues. Ralph Johnson of the GoF Design Patterns is quite involved there.
Regards, David www.testdriven.com ----- Original Message ----- From: "Vince Pacella" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, February 13, 2004 1:46 PM Subject: Re: [ADVANCED-DOTNET] Transparent Persistence How does a one-man development department pick up good object modeling skills? Referring to myself of course. Since I'm not in a larger department there's nothing to base my modeling on other than my intuition... Any good books or whatnot? Regards, J. Vince Pacella / OOCL Chicago 10.30 - 7.00 Central Tel - 773-399-6218 Fax - 773-867-5050 Cargo Tracking Online at: www.cargosmart.com and www.oocl.com -----Original Message----- From: Stefan Holdermans [mailto:[EMAIL PROTECTED] Sent: Friday, February 13, 2004 3:28 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Transparent Persistence 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(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 IMPORTANT NOTICE Email from OOCL is confidential and may be legally privileged. If it is not intended for you, please delete it immediately unread. The internet cannot guarantee that this communication is free of viruses, interception or interference and anyone who communicates with us by email is taken to accept the risks in so doing. Without limitation, OOCL and its affiliates accept no liability whatsoever and howsoever arising in connection with the use of this email. Under no circumstances shall this email constitute a binding agreement to carry or for provision of carriage services by OOCL, which is subject to the availability of carrier's equipment and vessels and the terms and conditions of OOCL's standard bill of lading which is also available at http://www.oocl.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 =================================== 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
