Data Mapper to relational database

Question

I've been reading the "Patterns of Enterprise Application Architecture" book and it has opened my mind to a lot of different designs.
I'm trying to design a large accounting system in OO. I'm unclear on how I should design the mapping inbetween the domain logic and database.
Should the controller classes talk to the data mappers?
In inheritance if my classes don't directly relate to tables should I have one data mapper or one for each class?
When I'm using a data mapper and I select all from a table does the mapper create multiple objects or does it return a result set?
If it creates multiple objects how does the domain logic sort this data?
Do I really need a Unit of Work to manage my data mappers? How hard are they to create? Is there only one Unit of Work class for all data mappers?

Answer 1

I've been reading the "Patterns of Enterprise
Application Architecture" book and it has opened my
mind to a lot of different designs.Usually the worst time to apply the stuff, because you're looking to use it before you really understand. But there must be a first time for everything. Great book, though.
I'm trying to design a large accounting system in OO.Wow, is this for personal education or a paid gig? I hope it's the former. If not, make sure that "build versus buy" is part of the decision. Would anybody write an accounting package in this day and age, with SAP, Oracle, QuickBooks, Great Plains, and a thousand others ready to buy?
I'm unclear on how I should design the mapping
inbetween the domain logic and database.
Should the controller classes talk to the data mappers?Depends on what you call controllers. I like to think of them as the classes that implement the service interfaces. The methods in the service interface are the use cases. I think the distinction between controller and service is very important, because a web-based app will certainly have a controller. If you fall into the trap of putting all the logic into that class, you can't use it WITHOUT the web controller. It also puts you right in line to turn this into a service oriented architecture.
The services will certainly call the persistence interface. Make sure you have one.
In inheritance if my classes don't directly relate to
tables should I have one data mapper or one for each
class?That's one way to do it.
When I'm using a data mapper and I select all from a
table does the mapper create multiple objects or does
it return a result set?I think it ought to return a Collection of objects. You should never return a ResultSet. That should be instantiated and closed within the scope of the persistence layer. ResultSets are database cursors, a scarce resource. They should be kept open for the shortest time and scope possible.
If it creates multiple objects how does the domain logic sort this data?You won't ask for all of them unless you have something sensible to do with them. If you're referring to the literal "sort", it's an easier question. Have the database do an ORDER BY in the SELECT. Hard to tell what you mean by this.
Do I really need a Unit of Work to manage my data mappers? You do if you need ACID properties for transactions.
So you're going to try to do all of this by hand? A hard job, indeed. You're talking about writing your own transaction manager.
How hard are they to create? Is there only
one Unit of Work class for all data mappers?I haven't read Fowler's book in a while, and I don't have it handy, but it's one Unit of Work per transaction when I think about the term. What you need is something that will demark transaction boundaries.
If you weren't writing this yourself, you'd be using JTA (Java Transaction Architecture.) That's what I'd recommend that you do.
But if this is an educational effort, knock yourself out.
%