Here is is a pattern that I'm using:
I call it NestedActivitity.
A NestedActivity may be a toplevel activity, that is, it's parent == null. Or it may be a sub-activity with a parent != null.
NestedActivity has methods begin() and commit(). if parent == null begin() opens a transaction. if parent == null commit() commits the transaction.
This trick prevents the child activities to directly access transactions. This trick also allows to have arbitrary nestings of business activities.
I don't know if this is a pattern that is already listed somewhere, maybe in one of Martin Fowlers books.
cheers, Thomas
Shane Mingins wrote:
H
I am using the OJB ODMG API with an application and I am wondering what people end up doing to avoid lots of code duplication for CRUD type activities.
If I am doing a CREATE I can create an instance of a new object and pass
that object to a store(object) method that can:
1. open (if not already) an OJB connection 2. start a transaction
3. persist the object
4. commit the transaction
If I am going to READ the object I can call a read(objectKey) method passing
the object key etc:
1. open (if not already) an OJB connection 2. start a transaction
3. create and execute my query, i.e. get the object
4. commit the transaction
5. return the object
But if I am doing an UPDATE I need to be able to read the object, make changes, and persist the changes within a single transaction. Therefore I cannot just reuse my read and store methods.
Ideally I would like to call a getObject() method on an object manager class and have it read or create and update.
For example:
CustomerManager mgr = CustomerManager.get(); Customer customer = mgr.getCustomer(name); // this either creates a new customer or returns existing
... do some stuff to the customer object ....
mgr.store(customer); // this will either persist a new customer or update an existing
The key seems to be how to start/abort/commit transactions around the CRUD actions. I was using the join method on the transaction object but I am not sure if that is a good approach or not.
Can anyone share some advice or perhaps resource that addresses my queries in more detail than outlined in the tutorials? I am guessing that there is some design pattern that perhaps address this but if it is too abstract (as a lot of patterns are) I get lost applying it to my actual situation.
Thanking You in Advance Shane
Shane Mingins Analyst Programmer Assure NZ Ltd Ph 644 494 2522
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
