Hey, As I am refactoring the current visibility rules I came across the RMI EntityStore as something that is trying to violate the visibility rules on purpose, which is a smell. When an Entity is changed on the client and the UoW completes so that the server-part of the RMI EntityStore gets to write the changes it currently has to look up the EntityStore of the Entity that changed, and work with that. This is a violation of the visibility rules, since only the Entity itself should see its EntityStore. The RMI EntityStore, basically being a part of the UI (albeit an advanced part), should *not* be allowed to see the store of the Entity.
This forced me to rethink what the RMI EntityStore is. Maybe it should be looked at like any other client in the application. Meaning, when the client applet/app asks for data and works on it the prepare() phase should not send data back, but rather a set of commands that reflect the properties that have changed, and the collections that have been updated, in the order they were changed by the client. The server part of the RMI EntityStore can then create a new UoW and apply the changes as if it was a local client. Then there would be no violation of visibility rules, since the RMI EntityStore would work with UoW+Entities rather than with EntityStores. It also has the added benefit of reapplying the constraints and validations at the serverside, thus ensuring that the client cannot do anything funky that goes against what really should be possible. It also has the added benefit that sending commands rather than state is usually much more efficient since it will only be sending the changes. Sending property-changes and association-changes is trivial, whereas ManyAssociation changes will require the commands to include more specifics on what methods were invoked (still relatively easy though). What say ye? Sounds reasonable? If so, I will refactor the RMI EntityStore to work like the above. /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
