dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

On Wed, Dec 23, 2009 at 5:42 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:

> As always there is not a single right and wrong answer here.  There are
> some things (usually different things) that might need to be validated at
> different levels of the application.  But things which might make a mess of
> the model should be validated by the model (or the service layer as I see
> Lars has just chiped in :-).  I'm not sure if I really buy the idea that
> communication of problems at the model shouldn't percolate up to the UI.
> Are we saying that from a UI perspective, an update, delete or add should
> allows be assumed to just succeed?  Of course these will sometimes fail and
> of course we have to feed that back up (whether by exception or return value
> - whichever is least evil).
>
>
Just to clarify... Right now we do validation of things like uniqueness and
non-null-ability in separate actions. If we push this down to the service
layer I do believe that this should happen in a separate method. It could be
the client/presentation layers responsibility to call that validation method
before calling the "business method". If the business method still fails we
are dealing with insufficient validation or programming errors. In that case
we could naturally handle that with a checked or unchecked exception which
could be caught in the presentation layer. But I do think mixing validation
and business logic code in the same method is not to separate concerns...