You might try and contact Ben Alex and request for usage of the ROO framework (maybe under some agreement?).
Printable View
You might try and contact Ben Alex and request for usage of the ROO framework (maybe under some agreement?).
Thanks, Oleksandr. That's a neat solution if the domain object is ever allowed to be in an invalid state.
If you have many domain classes that must be validated before saving, you'll probably have to extract a Validatable interface...
And keep in mind that interceptors can only throw RuntimeException while validation errors may be business exceptions, which are usually modelled as checked exceptions.
There is much worse problem there - you can not predict at which moment in time object will be saved and so where in your code you have to deal with this exception. Very likely, very far away from point where you are able to treattreat business exception meaningfully.
But, anyhow, kind of errors that we discuss now (attempt to save non-complete object) is rather programmatic error and not business error and so it is nothing wrong in the unchecked exception.
Note, that validate() itself may throw checked exception (as it is likely to be used outside of interceptor as well) and
interceptor converts it to the unchecked one (consider the interceptor as "last ditch" :) )
Regards,
Oleksandr
Well at least it is worth a try. Maybe register for the ALPHA/BETA test group ;).
Looks like the slides are available (you do have to register though).
http://www.springone.com/download/at...5/22_03_02.pdf
Thanks Karl for the link ..
Had a quick glance at the presentation. At one place he mentions DTOs are great for remoting. Couldn't agree more :cool: . But I am still not convinced why DTOs are being used for same JVM client applications. :( Every bit of separation of concerns, that come up in designing a domain rich application with a layered architecture, can be addressed, using the combination of domain objects (DO) and aspects. Why introduce boilerplates with no behavior ?
My $0.02.
Cheers.
- Debasish