« Hibernate Book Revie... | Main | iPod: Glad I waited »
20030429 Tuesday April 29, 2003

Validation vs. Business Logic In the manuscript I'm reading, I just ran into a diagram and overview of a layered architecture - and all of a sudden, it hit me. At work, most of our business rules are being implemented by Struts' Validator framework. In the case of indexed properties and more complicated rules, these reside in the validate() method of our action forms. So it's interesting to me that I'm using a business delegate to perform my business logic - when in actuality, all my delegates are doing is copying properties from a POJO to an ValidatorForm. So this begs the question - shouldn't validation (a.k.a business rules) be done wherever it is most convenient rather than only in the domain layer? Oh yeah, and most of this is just validation - our real business rules (comparing data for validation) takes place in Oracle stored procedures. And you know what - it works great!. So my opinion is - do whatever is easiest and makes the most sense. Posted in Java at Apr 29 2003, 06:18:27 AM MDT 6 Comments

Comments:

I would say that if you only have a web-based interface to your app, you're fine. If there is also a thick client that goes straight to your service layer, you'd need duplicate validation code.

Posted by matt on April 29, 2003 at 08:20 AM MDT #

As long as it is intuitive where to find it from a maintenance perspective. I remember wasting hours looking for a bug in a web app, only to find the offending code in a JSP - ouch! The more places you have to look, the longer it may take to fix problems.

Posted by Jason on April 29, 2003 at 08:29 AM MDT #

You should probably put it in in server-side distributable components unless you know for sure that you will never need any UI other than the web (and in that case, why aren't you using PHP or something easier to deal with?).

Posted by Dave on April 29, 2003 at 08:48 AM MDT #

The standard response that I've read in several places is that you should do validation multiple times and redundantly in order to correctly maintain constraints in a multi-tier MVC architecture. This does seem unneccesarily complicated, though..

Posted by Colin Evans on April 29, 2003 at 03:04 PM MDT #

The manuscript refers to a layered architecture. I guess it would be an in incomplete exercise to attempt to build a layered architecture and then implement business validations in the validator (since the validatons would need to be duplicated should you add another web / webservices / swing client to work with your business layer). I personally would either implement a layered architecture fully (ie. implement the validations in the business layer) or not at all. Your opinion - do whatever is easiest and makes most sense could get (mis?)interpreted as stick the validation logic in validator but implement a business layer separately.

Posted by Dhananjay Nene on May 01, 2003 at 03:01 AM MDT #

Something kept on bothering me about my last comment. I would be most comfortable using validator for enforcing business validations so long as one had separate validator.xml equivalents for presentation and business rules, and the business validations were triggered from within the business layer (i.e. by having the business layer invoke the validator functionality directly instead of using the struts plugin/integration).

Posted by Dhananjay Nene on May 01, 2003 at 05:38 AM MDT #

Post a Comment:
  • HTML Syntax: Allowed
Click me to subscribe
Matt Raible is a Web Architecture Consultant specializing in open source frameworks.
« May 2012
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today

Recent Entries

Tag Cloud

abbie appfuse denver flex grails gwt hibernate jack java jsf linkedin maven myfaces rails roller skiing softwaresummit spring springmvc struts2 tapestry travel vacation webframeworks wicket