I'm transferring to a new group that does not have an established code library for the data mapping/persistence layers. I'll have to look at third party persistence products like TopLink or, preferably, design a reusable mapping component. What are some good patterns for to look at for mapping? The system I use today uses a broker to match broker classes to domain classes. All SQL is contained in the broker classes in the mapping layer. GOF does not cover the broker pattern. Any suggestions on a good source on the broker pattern? What other patterns or design books might be good to look at for designing a mapping component? http://www.byteworksinc.com
[This message has been edited by Steve Mitchell (edited October 02, 2001).]
I have found Information Systems Architecture patterns in martin fowler's website at www.matinfowler.com to be very useful also an article titled "Connecting Business Objects to Relational Databases" by Joseph W. Yoder et al is very good...
posted 19 years ago
That is just what I was looking for! Thanks.
Originally posted by Santanu Barua: I have found Information Systems Architecture patterns in martin fowler's website at www.martinfowler.com to be very useful also an article titled "Connecting Business Objects to Relational Databases" by Joseph W. Yoder et al is very good...
Originally posted by Iain Lowe: Kyle Brown has written a paper on the subject of mapping Objects to RDBMS's. He has expressed his views in a pattern language he calls Crossing Chasms. Check it out at http://members.aol.com/kgb1001001/Chasms.htm
Thanks for the reference. My pattern language can also be reached through Martin Fowler's ISA patterns, also referenced above. I've been working closely with Martin on his ISA patterns, and I'm not ashamed to say that they're better written than my own. Mine are a bit more complete at the moment, but Martin is quickly moving to change that!
A high level approach I take when doing data mapping is to have a set of objects that acts as an intermediary between my in memory objects and my non-OO data. THis way, the rest of my system thinks it is dealing with an OO database, even though it is not. These layering objects are factories on one hand, creating objects from the database and updaters (for want of a better word) that move objects I need persisted into the rdbms. These layers aren't all that hard and are easy to maintain. It also allows me to write query objects that can work directly on the RDBMS. Relational databases have some really strong advantages if you don't need to worry about differences of the objects. For example, some applications I've worked on have had to worry about different nationalities. In my code, I'd use polymorphism to hide differences in tax rules, ... However, my databases typically could be easily split up so only data from one country was in any one data base. This allows for quick queries and extractions to be done in the RDBMS itself. ------------------ Alan Shalloway, Look for Jim Trott and my book: Design Patterns Explained Visit our site Net Objectives. Visit our on-line companion to the book
Alan Shalloway.<BR>Look for Jim Trott and my book: <A HREF="http://www.amazon.com/exec/obidos/ASIN/0201715945/ref=ase_electricporkchop/103-0514572-3811868" TARGET=_blank rel="nofollow">Design Patterns Explained</A><BR>Visit our site <A HREF="http://www.netobjectives.com" TARGET=_blank rel="nofollow">Net Objectives</A>.<BR>Visit our <A HREF="http://www.netobjectives.com/dpexplained/index.html" TARGET=_blank rel="nofollow">Design Patterns Explained Community of Practice</A><BR>Check out our <A HREF="http://www.netobjectives.com/xml/xml_cdrom_info.htm" TARGET=_blank rel="nofollow">CDROM based audio training in XML</A>