On Jul 1, 2005, at 10:32 AM, Michael Gentry (Yes, I'm a Contractor)
wrote:
> The benefits of this are you can isolate all of your validation
> methods in a
> separate class from the getters/setters and the business logic. In a
> complex application, the validation layer can be much larger than
> the other
> two layers (the application I'm maintaining is proof of this -- our
> most
> complicated validation class is over 200KB). You put the
> validation layer
> at the bottom of the chain, too, because it might need access to
> the other
> two layers.
>
> Of course, I could just be a loon, too. :-)
Actually, this sounds pretty cool. It would certainly take care of
one of the problems I'm running into. I'm retrofitting an app with
Cayenne. It was originally built around DB knowledge base component
that handled all the DB related items. Switching over to Cayenne has
been quite easy, but at the cost of transparency, which isn't sitting
too well with some others here.
For example, adding objects to relationships that haven't been
registered with a DataContext yet requires some sort of workaround.
The way I've been doing it is using a local collection to store these
added elements, and then during the validation phase, register each
of them with the parent's DataContext. This works, but now it's
quite evident that Cayenne is involved, which is not ideal.
Of course, in this particular case, if the DC check was deferred, as
has been tossed around before, then there's no issue. Maybe I'll
start looking into this a bit more.
-- Kevin
This archive was generated by hypermail 2.0.0 : Fri Jul 01 2005 - 11:04:45 EDT