Forums

by Michael J. >> Thu, 20 Jul 2006 23:32:06 GMT

Hi,
This is a query regarding the design of a class to control the transactional layer in a system. I.e. If there was a class representing a customer that needed to be updated, the executing method would typically use a controller method that would in turn use a standardised 'agent' class to perform the update.

The core functionality of this class would be:
- Edition control
- Locking implementation (although the controller level determines locking stategy)
- The actual creation/updating/deletion of the persistent data
- Transaction process flow, i.e. Check edition -> locking -> validation -> transaction
- Storing the relationships between transient data

In the past;
- I have either not used an agent and instead just used a transient copy of a class for any update, which involved having standardised 'transaction' methods on the persistent class. Not really happy with this approach as it weakens the distinction between the database and transaction layer. Also the code is less clear.

- or created a 'agent' class that replicated the persistent class closely. i.e. had all the same attributes etc. Main problem is the onerous nature of maintaining the class structure and the doubling up of the class structure.

My prefered approach would be a hybrid approach that would involve using an instance of an 'agent' class that referenced a transient copy of a persistent for the lifetime of the transaction process. i.e. Changing a customers name might look something like this;

updateAgent := persistentCustomer.fetchAgent;
updateAgent .myTransientCustomer.firstName := 'bob' updateAgent.doTransaction; // edition,validation etc done here

The main issue I have with this is that JADE does not to my knowledge have a 'friendly' language construct like most other OO languages. Which I could use to limit the updating of a persistent objects class properties to another single class. So in effect I have to supply a public interface (set method) to each property. I am not really happy with this as it weakens the seperation between database and transaction layer. i.e what is to stop some jackass from just using the set method from somewhere else in the code? I know all developers should be attempting to use best practice but I really want to force them

Does anyone else have a good strategy for controlling updates in jade or perhaps have a recommendation for improving my methodology?

Or has anyone implemented a 'friend' design pattern in JADE?

by Michael J >> Thu, 20 Jul 2006 23:42:14 GMT

Incase it wasnt clear, typically this 'agent' class would not be reimplemented and the hypothetical 'friend' I am talking about would in fact be the controller level of the transaction proces..=

by Torrie >> Fri, 21 Jul 2006 0:22:01 GMT

Michael

Rather than using set methods for each individual property, have you considered having one "setProperties" method for the class. The setProperties method could then take the agent or transient instance as a parameter. If no other set methods were defined on the class then the only way to updated the object would be via the agent.

If you use a transient instance of the persistent class, then I assume that the properties would be readonly or protected (if public then you have no control on the updates) Given this you may need to define two lots of set methods, one that the forms etc use to update the agent and another that the agent uses to update the persistent object. These set methods would need to check the lifetime of the object to ensure that they weren't used incorrectly.

I haven't investigated interfaces yet but they may provide a suitable way of separating out the functionality between a persistent instance and a transient (agent) instance.

Torrie

by dcooper@jade.co.nz >> Fri, 21 Jul 2006 1:36:55 GMT

Torrie's correct - this would be a good use of Interfaces in JADE 6.1.

You could define an Interface (say ICustomerAgent) that exposes only the set/get operations you want your transaction layer to be able to perform on Customers. Your Customer model/database class would then implement the ICustomerAgent interface. Now your code would become:

updateAgent := persistentCustomer.fetchAgent;
updateAgent .myCustomerInterface.setFirstName("bob"); updateAgent.doTransaction; // edition,validation etc done here

The myTransientCustomer reference becomes a reference to an ICustomerAgent interface (ie: it's of type ICustomerAgent, not Customer). Your fetchAgent method would still create a transient Customer object (so there's an actual transient Customer behind the interface), but by assigning it to an ICustomerAgent interface reference, all outside code sees only those operations defined on ICustomerAgent and not all of the public properties/methods on the Customer class.

Dean.

by Michael J >> Fri, 21 Jul 2006 2:16:57 GMT

Thanks both of you for your suggestions, I have not had a chance to look at all the Jade 6.1 functionality yet but will definetly look into that part of it.

Torrie, I was thinking of one big set method, the main negative in my reasoning was that personally i find it a little cumbersome to code in the style where all the required parameters for a big set method are avaliable all at one time. Still I suppose on further thought in the majority of cases the controller layer has most likely already assembled all the required params, so its definetly something i should re-examine.

by Michael J >> Fri, 21 Jul 2006 2:42:57 GMT

Ok, I have had a good read the of the documentation, and it sounds like a good tool, and would be well suited to my methodology. The only annoying thing (IMO) is that the methods created to implement the methods defined on the interface cant be defined purely as 'interface' methods and then ONLY be used via the defined interface. If you could do that then you could create an even more strongly bound transaction layer. Still its a good feature anyway!

by Anonymous >> Sun, 23 Jul 2006 21:24:56 GMT

Without a 'friend' relationship construct, there's a tendency to define too many properties and methods as public, so it's difficult to differentiate interface from internal implementation. Friends have been on the Jade wish list since day one - I hope it's getting closer to the top of the priority list. If classes AND interfaces could be defined as friends, would this be a way of providing Michael's 'interface method' restriction?