Our J2EE web-based applications are based on MVC pattern. We have 4 layers: View, Application, Domain, Persistence Our web based applications take input - data and actions - from user and perform CRUD operations. The data flows thru these layers and ultimately goes into persistent data store, like RDBMS. In such applications, guarantee of data integrity is of prime importance. The data in data store must go from one stable state into other. RDBMS takes care of ACID properties. However, still data might be corrupted. Business rules comes into picture here. Consider an example: We have Event with StartDate and EndDate. Constraints: - StartDate must be a valid date - EndDate must be a valid date - StartDate <= EndDate - Both dates are mandatory input. Now when user enters the date thru web interface, he enters string literal, for example. String can be empty, white spaces, characters that does not represent date [e.g. "somedate"] Thus we see that data requires different types of validations: whether user has submitted mandatory data, is it valid data, the relationship of one data with other data, etc. We can have different requirements: 1) Responsiveness of application [client side validations] 2) Many user interfaces - Web-based GUI, web services, etc 3) We want to display human readable error messages to user 4) We would like to avoid threats like SQL Injection But in all cases data integrity cannot be part of requirement. It must be mandatory to all applications. With this understanding, - What is the most appropriate approach to validate the data? - Who is responsible for guarantying data integrity [one of the layers, more than one of the layers, RDBMS]? - Should it be centralized or spread across layers? - If it done in different layers, what validations should be done in various layers? - Will Design by Contract concepts help here? [Thus using Java Assertions to our advantage. e.g. Code snippet: assert (starDate != null); starDate = starDate.trim(); assert ("".equals(starDate) == false); . . . ] - Is domain layer most appropriate layer to implement data validations? - Business rules can also be implemented at RDBMS level, thru use of triggers, stored procs, etc. Is that better approach than doing it at domain layer. If done at RDBMS, wouldn't there be problem in extracting the root cause from the SQLException and showing more user friendly error message? Your views/comments are welcome.
- Posted by: Sachin Raverkar
- Posted on: September 22 2006 01:19 EDT
- How you actually implement the MVC pattern by arijit dey on September 22 2006 04:16 EDT
- Re: What's most appropriate layer for data validations in MVC ap by Christopher Stach II on September 22 2006 09:45 EDT
- Re: What's most appropriate layer for data validations in MVC ap by vaheesan selvarajah on September 22 2006 17:38 EDT
- Re: What's most appropriate layer for data validations in MVC appl? by Srikanth Shreenivas on October 02 2006 14:04 EDT
All of them, with your View layer being optional as you have no control over it (at least not with a web app.) You can get away with removing some validation layers if you are the only caller (i.e., your input validations are in line with your DB schema and are guaranteed to work.) It's still smart to have them there, because mistakes will be made.
In my opinion , the level and kind of validation will vary upon the layer where it is present. However all layers should have validations. This is required because you not only want business rules to be protected but also security concerns. I suggest you comeup with a list of all validations that are Manadtory and nice to have. Give weights to the nice to have one and evaluate alternatives. Implement validations for Mandatory ones in all layers as this will have big impacts on your business. then simple validations like formating can be pushed to the front end and the business rules must be checked before any critical operations are performs...mostly in the middle tier. Finally the persistance/Domain level validations should be to hold the integrity. Overall you need validations at all layers. One quick advice.... NEVER EVER RELY ONLY ON JAVA SCRIPT VALIDATIONS. They can be easily broken using web proxies. Have backend validations too. Performance can be compromised when data integrity and security are crucial. Vaheesan Selvarajah WSAD and RAD Service and Support IBM Toronto Lab
Even though validations do spread across layers for various reasons, what we should try is to devise mechanisms to express them once and avoid having them duplicated at multiple layers. Fortunately, There has been some work done in this direction. For example take a look at Trails framework (http://www.trailsframework.org/). Following is the excerpt from the Trails website: Trails is a domain driven development framework in the spirit of Ruby on Rails or Naked Objects. The trails project aims to make Java enterprise application development radically simpler by allowing developers to focus on the domain model and having other portions dynamically generated. We will leverage existing technologies such as Spring, Tapestry, and Hibernate rather than reinventing the wheel.