First of all, just for the sake of pointing out what may or may not already be obvious, just because you use a decorator for one object certainly does not require you to use decorators for all objects.
Secondly, in my personal opinion, the business object (decorator in this case) is exactly where the business logic should be maintained. If your object does nothing but hold data, why bother with an object? Just go with traditional structs, arrays, and queries. In order to avoid a corrupted cache, if you are requesting an object for editing purposes, you should always call clone() on it. I suppose that you could check getIsDirty() prior to the save and, if true, grab another object from Transfer to get your "old" values. I obviously do not know how you're modeling your application, but it seems to me that if all of the logic for the entire application is held in "one place", the application would become very messy and difficult to maintain in a hurry. HTH --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
