Class Responsibilities and Persistence

[dragonwell]

I have been using an O/R Mapper for persistence. The mapper basically has one utility class with static methods such as "GetObject(type)" and "PersistChanges(object)"

This follows the broker/manager paradigm, in that objects themselves are not responsible for persistence behaviors (CRUD), but the role is handled by a manager class, or "broker". I have determined this to be the most correct way to persist business objects, which is of course open for debate. My issue is with transactional saves - objects don't know if they are participating in the context of a transaction and should not be doing CRUD without knowing if their parent/child objects are involved.

For simple applications this works fine. In fact it simplifies the layering needed to the point where a Data Access LAyer (DAL) is not really even needed - I just use the broker instance right in my GUI code do crud business objects.

Now, in a more complex application I would like to hide the O/R mapper from the GUI layer, so that it is insulated from changes to the mapper or all out replacement. I am trying to eliminate, or at least substantially reduce, the tie-in to a particular persistence mechanism.

The way I have done this is to create a "DataManager" class which consists of many static methods, specific to the current application, i.e. - GetCustomer(cusID), SaveCustomer(), etc. These static methods are only a few lines each as they are using an internal instance of my O/R mapper to do the dirty work.

Before I know it though, this manager class keeps growing and growing... And it seems that I am creating more and more specialized methods. So I am now questioning this design. Is this what is known as "amenic data layer"?

I have thought about putting the CRUD behaviors into the business objects themselves, altough that breaks the rule of responsibility I am assuming, and plus the O/R Mapper-specific code in now scattered throught the assembly, increasing the tie-in factor.

So, what I have is working, but it seems like it is maybe not so correct.

Any comments welcome....




Greetings,
Dragonwell

 

[stevexff]

Writing your own transaction manager is not something to be undertaken lightly, and it's one of the reasons that CORBA was never going to catch on. Why would anyone want to reinvent the wheel every time they wrote a program?

Legacy transaction managers like Tuxedo and CICS allowed application programs to be run in a transactional environment without the applications having to really be aware of it - all commits, rollbacks, and resource integrity are handled by the transaction manager.

Assume you are using Java, so to get similar benefits for your applciation, have you considered an EJB container of some sort (WebSphere, Weblogic, JBOSS et al)? Container-managed persistence (CMP) of entitiy beans gives you everything you need; automatic support for transactions, automatic object persistence to JDBC-compliant databases, and more.

The first two you have to pay for, but JBOSS is open source and downloadable for free.

You just create your classes, and the container takes care of the rest (OK, probably a gross over-simplification, see your local book shop for any number of doorstep-sized books on J2EE, but you get the general idea ).

 

[dragonwell]

Thanks for your reply, stevexff. Actually I'm using .NET, so no CMP for me. .NET is still very young when it comes to persistence frameworks, but it's growing up steadily.

But - the pricinples are the same though in many respects, based on what I've read. The closest thing to what I'm using would be OJB. (or is it OBJ?)

Now that I've got it, I jsut need to figure out the best way to incorporate it into the apps I write. (use it directly in the gui layer code or wrap it in static manager classes).

Greetings,
Dragonwell

 

[dragonwell]

Look at it this way -

Class: Manager
Static Methods:
GetObject(Type)
GetObject(Type, key)
GetCollection(Type, criteria)
PersistChanges(object)

I could easily use Manager directly in the presentation layer of my application. But I want a layer of abstration between the presentation layer and the Manager which, to me, is the data access layer. The primary reason is that I might use a completely different "Manager" which has it's own API, or I may even decide to just use low level provider-specific data-access code.

So I have a layer containing the business objects which are persisted by the Manager. How should the business objects interact with the Manager without the presentaion layer knowing that the Manager exists? Should the the business obejcts expose CRUD behaviors and use the Manager internally?
Save()
GetInstance()
Delete(), etc.

OR should I create a "facade manager" which has a bunch of static methods specific to my application, i.e -
GetCustomer( customerID )
SaveCustomer(customer)
GetCustomers(), etc.

That's what I did because it isolates the usage of the Manager to one class and if I get rid of the Manager and use somethign else, at least it's only one class that needs to have all it's methods changed.

What doesn't feel right is that it seems that some of the responsibilities that I think are of the business objects themselves, are getting put on to the ManagerFacade. Some of the business logic requires database calls, and since the business objects aren't allowed any of this they have to defer methods to the ManagerFacade, and thus end up as dumb data-transfer objects.

Anyone?

Greetings,
Dragonwell