Data Mapper to relational database
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?
> 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.
%
just to clarify: I think you'll have controllers that will work with services to accomplish a single use case. there are two interfaces here: controller and service. persistence is another.
one other point: i prefer data access object these days (DAO) for the persistence interface. your implementation can be data mapper, object/relational mapping of a domain model, or anything else, but the interface shouldn't change.
it would look like this for a Foo business object:
public interface FooDao
{
public Foo findById(Long id);
public Collection findAll();
// other finders for other WHERE clauses.
public void saveOrUpdate(Foo foo);
public void delete(Foo foo);
}
Google for DAO.
%
This is for a company and it's based on an Accounting system that they use and have been for a long time. My boss originally designed it in informix and now he wants to redesign it and sell it.
I'm going to use Java Server Pages, with Java Objects for my Domain Logic.
What is ACID? Do i need to worry about it if I'm using JDO?
It seems that every corner I turn in designing this large system there is something new to learn and get used to. I'm trying to find the best path to make it easy to manage, create, update in the future and maintain.
I've been looking into JDO for my persistence interface but I don't know if I have to install that or if it's already installed in JDK1.4.2?
If I do, how do I install it on a unix system?
Someone suggested to me that I use JPOX, have you heard of this? Is it any good?
> This is for a company and it's based on an Accounting
> system that they use and have been for a long time.
> My boss originally designed it in informix and now
> w he wants to redesign it and sell it.
Good luck with that.
> I'm going to use Java Server Pages, with Java Objects
> for my Domain Logic.
So web-based accounting software. Pay special attention to security.
> What is ACID? Do i need to worry about it if I'm using JDO?
Google for it. It stands for atomic, consistent, isolated, and durable - four essential attributes of transactions. You'll want it no matter what kind of persistence technology you use.
> It seems that every corner I turn in designing this
> large system there is something new to learn and get
> used to. I'm trying to find the best path to make it
> easy to manage, create, update in the future and
> maintain.
Let alone being an expert in the domain. You've bitten off a huge problem. Are you the only developer/designer/architect on this?
> I've been looking into JDO for my persistence
> interface but I don't know if I have to install that
> or if it's already installed in JDK1.4.2?
No, JDO has to be added. There are lots of implementations, some of them open source. Kodo is one; you might find others here:
http://www.jdocentral.com/
> If I do, how do I install it on a unix system?
It'll be a JAR you put in your CLASSPATH.
> Someone suggested to me that I use JPOX, have you
> heard of this? Is it any good?
No, I haven't.
You have bigger problems than persistence.
I'd recommend that you look into Spring, WebWork, and Wicket:
http://www.springframework.org
http://www.opensymphony.com/webwork/
http://wicket.sourceforge.net/
I recommend Spring, but these are all frameworks that might help you structure this application.
%
