Objects From Records
Objects From RecordsIn PLoPD'94 Proceedings (ed. Schmidt & Coplien), ChamondLiu and KirkWolf cite a pattern called Objects from Records where data access responsibility is transferred from the Domain (business) object to a Record Class. We're an insurance company with a large amount of relational (DB2 and Sybase) data we need to access and update. Does anyone have any thoughts, experience, feedback on using this approach or examples? Among the general questions that come to mind are:
SteveGoodman?, sgoodman@charm.net, sgoodman@USFG.E-MAIL.COM
You may not want to reinvent this wheel. There is a commercial product that helps to connect C++ and relational DBs. The company is Persistence, San Mateo, CA, (415) 341 7733 & 341 1280, ask for Paul. No, I am not a stock holder or the like.
-- DennisDeChampeaux?
There are others besides Persistence. Ontos has a similar offering and there's another I don't recall offhand. Write to my private address if you'd like contact info. I do not endorse either product.
-- Mike O'Keefe, meokeefe@ii.mke.ab.com
How do you sync Object attributes to Record attributes to RDBMS column content?
In the work I've done, the domain objects had a status field that tracked their state vis-a-vis the RDBMS, eg:
created -- new object clean-- matches database dirty-- existing object that has been changed condemned-- object slated for deletion deleted -- object that has been deleted from the databaseWe also used a special "key only" status that handled objects that were known by reference but not yet read in.
Can your RDBMS structure be totally distinct from the Object model structure?
No. They are different ways of expressing the same concepts.
Where should business logic be stored? (Domain Object, Record Object RDBMS row?
I've had the best luck with keeping it in the domain objects--database triggers are also useful but they have shortcomings, since you need to keep the model in memory consistent with the database.
Should the wrapper or RDBMS methods be in Record Class(es) or separate?
I've always put them in record classes, but we also had an in-between layer that was responsible for mapping the domain objects into the record classes and vice versa. The domain objects defined a minimal abstract interface for this layer and connected to it via a static class reference.
Is interclass messaging an issue?
Never had problem with it. Persistence is quite good. The only headache with it is that it the code inserted into the domain objects to support the interface to their database layer is quite complex and deeply embedded into the objects it generates. As long as you are planning on staying with platforms it supports (quite a few, but no DB2 the last time I checked), this isn't a problem.
It is *definitely* a big productivity enhancer.
-- PaulSteMarie, pstemari@well.sf.ca.us, pstemari@erinet.com
NeXT has built an entire framework around this approach, called Enterprise Object Framework. The white papers, etc., are available at http://www.next.com . Specifically, these may be of interest:
-- DanielGreen
You might also consider:
There are 2 aspects to this problem: technical and business model. I agree with the several thoughts about products which map a table to an object. Those may be used to manage the technical. Some of your questions (below) are business model and methodology issues. I'll address a few of these from the perspective of Object-Oriented Business Engineering.
Can your RDBMS structure be totally distinct from the Object model structure?
Yes. The mapping can be [business object:table] 1:1, 1:n, n:1 or n:n... this is a function of the respective business model and legacy data structures. On the other hand, there's the tech capability issue... does the "lense" product selected to link the object and relation allow this... some do, some don't.
Where should business logic be stored? (Domain Object, Record Object RDBMS row?
Business object, most likely in the Operational model level specializations (as opposed to the Enterprise model generalizations).
Should the wrapper or RDBMS methods be in Record Class(es) or separate?
The term wrapper could be applied at several levels. In general, the products which provide SQL access are wrapping the DBMS. There's another issue of wrapping those classes to make a record object look like a screen scraped object... i.e. it's all storage at that level, and the business object just knows to talk with a general storage capability.
Is interclass messaging an issue?
At what level... technical or business object? Business object... yes, because they interact in the course of performing business processes. Technical, perhaps... but I need to better understand the question.
Are there are other patterns or combinations that would address this "impedance" mismatch between Objects and Relational Modes?
There is not really an impedance mismatch between objects and relations in a business application environment. If you think of the RDBMS as an instance storage mechanism, and the record/wrapper class as a mechanism to provide an object/messaging interface, the RDBMS is just one more store. The record class sends a particular variety of message to the RDBMS interface, which lacks some of the usual OOP character but still...
-- RobertShelton?
I have a different perspective on this than many of the other responders. As I have written in chapter 4 of my book (citing below) it is sometimes beneficial to separate the object model from the mechanisms that are used to store the data. The object model encapsulates *business policies*. The database provides *storage mechanisms*. These two concerns are extremely different, and often ought to be separated.
To accomplish this I often use the 'proxy' pattern. I provide a long example in Chapter 4 of my book. The main idea is to create an abstract class for each object that needs to be stored in the database. One derivative of this class implements the business policies (call this class the 'object model'). Another derivative operates the DBMS, creates the business object, and delegates method invocations to it (I call this class the 'surrogate').
Robert Martin Prentice Hall, 1995 ISBN 0-13-203837-4 For Information: Send email to books@prenhall.com Or call Prentice Hall at 1-800-223-1360Re: "The object model encapsulates *business policies*. The database provides *storage mechanisms*..."
I am compelled to disagree here. DatabasesAreMoreThanJustStorage. Sure, you can use them or perceive them as being merely "for storage", but then you'd be ignoring a powerful tool and probably reinventing the wheel. The issue seems to be that object proponents want to stay with an OOP view of the world and thus want the RDBMS to be merely a dumb filing system that serves objects. Doing so has a cost. -top.
[Note the copyright date on the book, which means its content is even older. As of this writing, it's at least 15 years old. Some of the views on this page, the above included, are outdated. It's notable the degree to which the explosive growth of dynamic Web sites, underpinned (largely) by SQL DBMSes, have pushed the DatabaseIsRepresenterOfFacts and DatabasesAreMoreThanJustStorage viewpoints from the theoretical margins to mainstream practice.]
These two issues are really the same thing: the management of concurrent update.
My understanding is that transaction management is not directly related to concurrent access, though concurrent access makes transaction management more difficult.
There is a need for transaction management in every application. Transactions (or work units) must be completely carried out or not at all. That said, my question remains: How should model transactions be mapped to RDB transactions?
In my opinion, it is a responsibility of the object model to understand that it can be updated concurrently, and that transactions need to be managed. However, the object model should not know about the transaction mechanisms employed by the DBMS; instead, the surrogates should perform the necessary translations.
I certainly agree with your point of view. It is a statement of policy. Nevertheless I'm searching for specific answers to the above questions. Not the "what", but the "how". I can see the importance of managing concurrent access from inside the mapping layer in a transparent way, but it seems difficult. Both a "lock on load" and a IPC scheme have serious drawbacks.
While not expressed in pattern terms, there is an interesting intersection between Sr. Aqez (Anez?) recent posting in this group relative to transaction responsibility and a discussion I have been involved with elsewhere about general strategies of program system architecture for developing applications with an eye to distributed, N-tier deployment. The context there is an OO4GL, but it seems that the principles should remain invariant.
In that discussion, some principles have emerged (I wish I could report consensus, but I suppose that is asking too much) which are based more on wrestling with the empirical necessities of the situation, but which serve as reminders of essential principles which we have all read before, but which sometimes get lost in haggling over detail and form. In particular, one of these relates to keeping clear that the "transaction" as a property of the business rules is a property of the object which governs business logic and must be clearly distinquished from the operation of the data objects which it supervises and their interface to the databases with their physical transaction properties. Since the design goal in this case includes having data objects which articulate with databases from multiple manufacturers, the details of the physical transaction controls will vary from object to object, but this matters not at all to the controlling business logic object as long as it has the ability to commit or undo a controlled set of work.
In a similar vein, there is an agreement between the user interface and logic objects as to what constitutes the contents of an exchange, but the unit content of this exchange need have no fixed relationship to the units of exchange between the logic object and the data objects. I.e., the UI object operates in terms of a user view which needs to map onto a data structure, but the UI object need have no awareness of that structure.
In that exchange, the key element to me whenever it became unclear how two components should interact has been to step back and ask what it is that constitutes the actual exchange or work. Often, in thinking about simple cases, it is tempting to muddy this essential interface because it seems like it is easier to get the job done if one is less "pure" about the connection, but looking at more complex cases makes it clear that living the pure life is clearly the better approach.
-- ThomasMercerHursh, thomas@cintegrity.com
Agreed. As an extension of that concept, our policy managers (the term I use for what you call a business logic object - because it is a "manager" object that encapsulates business policy) can invoke the services of "sub policy managers" for complex transactions that actually involve more than one business policy. An axample is for entering an order, determining the tax might be done by a taxation policy manager, and calculating the discount might be done by the discount policy manager. The attempt here is to encapsulate a specific business policy. The intent (of course) is to limit the impact of changes to that policy.
-- StephenMcHenry, stephen@softi.com
I have a handful of useful URLs for Object-Relational mapping that can address this issue. Some of them may be referenced other places in Wiki.
Check out the CrossingChasms page here on Wiki.
You could, of course, try writing directly to KirkWolf. I know he was happy with the ObjectsFromRecords design, and he and Chamond and the rest of the team used and improved it over several projects. Of course, as the above people would be pointing out, his work was in the 1993-1996 time frame, and since then a number of OO - relational products have come out, reducing the need to build one oneself. --AlistairCockburn
EditText of this page
(last edited December 23, 2011)
or FindPage with title or text search