EJB design: MVC pettern on J2EE

  1. MVC pettern on J2EE (3 messages)

    I am adopting the MVC pattern where my JSP as view, servlet as controller and model as EJB.

    My query is, should I use the control (servlet) as a pre-condition layer where it does all the data validation, formatting before passing the data to the model (EJB)?

    On the view (JSP), I have put is some presentation logic such as .. if true display this else display that.. Have it violated the MVC model pattern?

    In you opinion, where the data validation and formatting activities should reside in?

    Thank you

    Threaded Messages (3)

  2. MVC pettern on J2EE[ Go to top ]

    It depends, to my mind, on whether there are any other clients for your controller layer than this particular view (JSP.)

    If there are, then you should put the validation in the layer they all talk to. If there aren't then it's really up to you.

    Note, if you put the validation in the servlet, then you are effectively opting for programming by contract with the EJB. In other words, the beans don't validate the parameters, it's up to the caller to only provide valid ones. I am not a fan of this myself.

    For myself, I would have helper classes that validate the parameters. In a project I worked on we wrapped the parameters in a collection with an interface and had several implementations of that interface. One contained an HttpServletRequest and was used for the HTTP interface. Another was built around a HashMap and the EJB clients used that. We then had helper classes for the beans which took the interface and validated that:

    1) The required parameters were present, in the right number, of the right format, within the correct range and of the correct length.

    2) No mutually exclusive parameter pairs were supplied.

    3) No parameters we were not expecting were present.

    If you do all 3 of the above, then you stop the hackers who make their first attempt to blow up your system simply fiddling with the URLs.

    If we got any of these situations, we simply threw an InvalidParameterException which contained detailed information of the problem. The facades to the system (in your case the servlet) caught that exception, logged it and then sent a 400 code back, which caused the web server to display a pretty error message, but which did not reveal any of the detail of the error, since this would give hackers useful information.)

    For me, that makes the most sense. As long as you wrap it up in validation helper classes rather than profilerating the beans with the code you'll keep the code base simple, and allow for future interfaces other than JSP.

    As for (if true display this; else display that) that's pure view logic from what I can see and it's OK to use it.


  3. MVC pettern on J2EE[ Go to top ]

    Depends on what time of validation you are talking about. If it is more complex, business related validation you should do that in the ejbs because that's where the business belows. on the other hand, if it is testing whether an argument is null or not this should be done somewhere else. imho, design by contract is better. it leads to better managed, more "robost" systems.
  4. MVC pettern on J2EE[ Go to top ]

    All validations inside the control layer are not business logic related. Basically it checks for null value, data format such as ID, date etc. before passing the data to EJB. i.e. the data validation routine is build in side the control layer and not in the value object wrapper.

    In the case of entity bean ejbCreate method, I pass in the value object (constructed in the control layer) to wrap up all the properties. Is it a good idea? If it is not, Why?