Was that the project that was mentioned in a lighting talk at the London JUG by any chance or a different one?
I could see a benefit for immutable object for those that live in a Servlet container session cache especially if the web container could be clustered and everything in the Session needs to be replicated across servers. The mutable versions would play nicely with an ORM. At this point I am not using any ORM and there are no domain objects at all in the system apart from some demonstration ones I created. I have been demoing with plain JDBC population (which is tedious) but it avoid having to add a dependency on the persistence API at this stage (though the mutable objects are ripe for modification in the future to add ORM annotations to them. At this point the work I have done may not go anywhere as the use of domain objects has not been well received so far. On 21 December 2011 13:49, Graham Allan <[email protected]> wrote: > That kind of arrangement sounds familiar to me. The mutable versions are > used for write operations (e.g. the user changing data through a web page), > the immutable versions for read-only operations (e.g. performing > calculations, generating reports etc). In my scenario I have the added > problem that the mutable versions are by far the more common throughout the > codebase, and I use a mutable->immutable converter for trying to wean bits > of the code off the mutable versions when they don't need them. It sounds > like you're in a better position, where you can make the choice of > immutable/mutable to begin with. > > If you want to have data changing in-place in your database, rather than a > "clone with modifications and deactivate the old" model and you want to use > the mutable versions in your code, then I don't see a way around having the > different classes. Another approach would be to only deal with the > immutable versions in your domain logic, and use something like the > repository pattern to modify the mutable object when you want to persist it. > > I don't know if Hibernate is your ORM framework, but it has a feature I > found handy for fetching immutable objects, the "select new" syntax. > > A tangential point, but there's other (better?) reasons to have immutable > objects than just being thread safe, and that is how much easier it is to > reason about them. > > And finally, on a shamelessly self-promoting (some may say 'shilling') > note, if you want a way to automatically check your classes are/remain > immutable, check out my project here: > http://code.google.com/p/mutability-detector/ > > Kind regards, > Graham Allan > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" 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/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" 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/javaposse?hl=en.
