it
depends on the semantics of the app: if those DTO's are not to be modified by
the people obtaining references to them, at least directly, then they should be
inmutable; or mutable otherwise. Inmutable DTO's might be cached
more efficiently since you know they need not to be written back to
the DB. Inmutable DTOs could also be optimized for
serialization. But basically, it's a matter of your business
rules, and encapsulation. There's a bunch of articles on the subject (including
versioning support for mutable DTOs) in theserverside.com.
I use
mutable DTOs as a rule of thumb, and decide whether or not to persist into the
DB based on a set of business rules, which mainly take into account that the
logged in user has modify permissions on that particular Entity instance (or DB
record, if you will). Since I usually build libraries to be used by third
parties and there's the possibility of malicious use of my apps, I don't rely on
plain Java to ensure that a DTO class is inmutable(esp. with the bugs in
reflection in some JDKs).
My
2c,
Juan Pablo Lorandi
Chief Software
Architect
Code Foundry Ltd.
Barberstown, Straffan, Co. Kildare, Ireland. Tel: +353-1-6012050 Fax: +353-1-6012051 Mobile: +353-86-2157900 www.codefoundry.com Disclaimer:
Opinions expressed are entirely
personal and bear no relevance to opinions held by my employer.
Code Foundry Ltd.'s opinion is that I
should get back to work.
|
Title: Message
- Value Object - mutable/immutable Glenn Dickson
- Re: Value Object - mutable/immutable Glenn Dickson
- Re: Value Object - mutable/immutable Glenn Dickson
- Juan Pablo Lorandi