In 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:

	* How do you sync Object attributes to Record attributes to RDBMS column content?
	* Can your RDBMS structure be totally distinct from the Object model structure?
	* Where should business logic be stored? (Domain Object, Record Object RDBMS row?
	* Should the wrapper or RDBMS methods be in Record Class(es) or separate?
	* Is interclass messaging an issue?
	* Are there are other patterns or combinations that would address this "impedance" mismatch between Objects and Relational Modes?

Any  help/comments greatly appreciated.

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 database

We 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:

	* http://www.next.com/NeXTanswers/HTMLFiles/1709.htmld/1709.html
	* http://www.next.com/NeXTanswers/HTMLFiles/1928.htmld/1928.html
	* http://www.next.com/Products/EOF/EOFWhitePaper/EOF.html
	* http://www.next.com/Products/PDO/ArchForChange/Arch.html

They don't have a write-up that specifically mentions the patterns involved  
in creating EOF, but I thought it might be interesting reading, given the
previous questions.

-- DanielGreen 

------

You might also consider:

	* DBTools.h++ from RogueWave Software (http://www.roguewave.com)
	* SQLObjects++ from Objects++ Software Corp (I think)

-- SteveKahn, MCI Telecommunications

-----
	* DBTools.h++, from Rogue Wave, provides an object-oriented interface to SQL databases.
	* RW-Metro, from Rogue Wave, is an object-to-relational mapping package.

--BetsyHanesPerry, Rogue Wave 

---------

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-1360

Re: "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.


JuancoAnez

------------

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.

	* http://www.ambysoft.com/persistenceLayer.html
	* http://www.ambysoft.com/mappingObjects.html
	* http://www.ksccary.com/Articles/PatternLangForRelationalDB/PatternLangForRelationalDB.htm
	* http://www.objectmatter.com/vbsf/docs/maptool/ormapping.html

-- StevenNewton, snewton@io.com

----

Check out the CrossingChasms page here on Wiki.

KyleBrown

----

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