I just HAVE to step in. > -----Original Message----- > From: Moderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of Stefan > Holdermans > Sent: Freitag, 13. Februar 2004 12:15 > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] Transparent Persistence [WAS: > Web Services, Remoting and Coupling] > > Frans, > > > First of all, let me say that 'transparent > persistence' is a > > good candidate for buzzword bingo. What exactly is transparent > > persistence? Is it the total absence of any persistence logic > > whatsoever? Or is it the absence of a separate > broker/adapter object > > so all persistence behaviour is inside the object? > > I think, for me transparent peristency is about keeping the number of > places where peristency-related code appears as small as possible. > Calling a Save method from
Hmpf. Transparent is defined as transparent. 100%. Look it up in a dictionary, please. Transparent does not imply "partially transparent". When you want a "low intrusive" system, please use an approprriate term, but do NOT use the word "Transparent". Saying that you want transparent persistence and then assuming this is "low intrusive" is like saying your girlfiend is "just a little pregnant". Just in case you do not know (like most people) there is exactly ONE system on the market that makes transparent persistence, and this is in the java world. This is done by GEMSTONE. With GEMSTONE you really have nearly transparent persistence, with just a little "stitch" of distortion around. You have a database that is GARBAGE COLLECTED, you have no save method, no nothing. Now, this is ONLY possible as Gemstone heavily owns the runtime - basically the transparent persistence is done in the Gemstone java vm. Java objects are persisted automatically as long as they tie in some way to a "Stone", which is a persistence anchor. Like to a collection of all customers etc. And any referenced object IS persistet. Amazing system. Anyone thinking he wants transparent persistence should have a look there what this means. Note that even there you have a query system, but it CAN be argued in this case that the persistence side is transparent. While querying is a core requirement for persistence, is has, after all, nothing to do with the persistence of the objects per se. Everything else is anything but transparent. And with all respect I am pretty tired of people asking for "transparent persistnece" and abusing this term without actually knowing what this entitles. > presentation-layer code is a good example: I don't like Save methods > hanging around in the GUI. I thinks this means that persitence-related > code is to be pulled out of an app's entity classes and pushed into a > central service. This service, then, is to be called from as few > places as possible. (Just brainstorming here.) I would skip the "as few places as possible". Where weh ad IMHO great success in in our O/R mapper named "EntityBroker" is basically an industry standard approach. You get your pobjects from a broker which is basically also the transaction. Comit the transaction and all changes are saved automatically, in the correct order. Any explicit save is a child's play, so to say. When you explicit persist an object the moment you want it to go into the database (Save method on objects) you have the problem that at the moment you commit changes you: * Have to know which objects are new / changed / deleted. * Have to make the necessary inserts in the right order. Maintaining these two requirements manually is not smart and normally the sign of a badly designed persistence system. I have a transaction, and I use a persistence layer. All I should have to do is actually say I am done with changes. This THEN naturally rules out any save method on a specific object. > > > There is no reason for panic though. If you look at > it in the > > way that entities live in the database, and in memory you only hold > > mirrors of these entities, (which comes down to as much stateless > > programming as possible) it's more acceptable you have multiple > > mirrors somehwere in memory. If you think in objects and that these > > have to be saved somewhere sometime, it's much harder to accept you > > have multiple instances with the same values or better: > > representing the same entity. > > Mmmmm ... Okay. But the thing I like from the 'hard way' is that it > centralizes the application layer instead of the data layer. No, it does not. The application layer can be as distributed as you want. We work on such a system right now (a CMS). The DataLayer (SQL Generation etc.) is centralizsed on the server (which you connect to), while the business layer is downloaded into the client. Never forget that you work in .NET - you have a TON of nice methods of making sure that the busienss logic is correct, distributed, up to the corerct version etc. In case of what we build into the EntityBroker, the Data Access Layer (or: ObjectServer) can serve you a list of DLL's that need to be there (with full names) and even sync the dll's into a directory for caching. There is no need to centralize the application layer if you do not want ti. All it takes is some work. Thomas Tomiczek THONA Software & Consulting Ltd. (Microsoft MVP C#/.NET) (CTO PowerNodes Ltd.) > > Regards, > > Stefan > > =================================== > 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 > > =================================== 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
