What's most appropriate layer for data validations in MVC appl?


General J2EE: What's most appropriate layer for data validations in MVC appl?

  1. 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.
  2. Hi sachin! The requirement that you have is almost common to all the enterprise applications.Validations are inevitable and how they can be implemented depends whole upon how you are going with your design, in this case MVC and offcourse how strictly you want to adhere to it. Under MVC, there has to be a strict separation between view and controller,but often the contract is mixed to perform well. There are various validation options for you.JavaScript I think is the most basic choice you can think of, you can embbed the scriptlets in your views and let it do the validations.But it does not strictly follow MVC rule, you will still have to supply user input data to javascript.Some validations like checking date formats can surely be done on client side but validations like checking for user existence will require a server side trip. If you are using servlets as controllers, you can put the validation logic there.And if you need to access the datastore then Model has to be contacted.But in essense, controller is the place where validation can safely reside. There are many validation frameworks available like Struts Validation framework, Spring Validator,Commons Validator, and ofcourse your own customizable validator. The view must know how to display data like displaying proper error messages etc, The controller should play the part to control the workflow and model is offcourse is one which does all the things but still de-coupled. So the moral of the story is, study the level of validation and then decide which one to use. Though this reply does not give you anything concrete but can show you a way.You can post more for specific queries. cheers, http://javaicillusion.blogspot.com/
  3. 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.
  4. 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
  5. 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.