How can I do data validation using CMP 2.0 ?


EJB programming & troubleshooting: How can I do data validation using CMP 2.0 ?

  1. How can I do data validation using CMP 2.0 ? (9 messages)

    Lets say that I have a rich data model with many classes and relationships. What I would like to do is to solidly lock down the data model using exception throwing data validators. Therefore if a user passed an invalid piece of data to the set method, he would get an exception rejecting the data. Example:

    public class Person {
      public void setName(final String name) {
        if (name.size() > 30)
          throw new IllegalArgumentException();

    The idea being that I can only give a name if it is 30 characters or less. Now in CMP 2.0, this class would look like ..

    public abstract class Person implements EntityBean {
      public abstract void setName(final String name);

    Because i have no control over the fields, I cannot check the data in the setter method. How does one overcome this deficiency? I cannot leave the data validation out because it would leave a hole that i could drive a truck through and yet i dont know how I can validate it.


    -- Rob
  2. Hi,

    You could use a session bean as a client to your entity bean. Meaning, the session bean takes the data from the user/client and then validates it(if necessary throws exceptions) before writing it to the underlying data store(entity beans).



    Meka Toka
  3. For each field in CMP Entity Bean you can create non-abstract method where you can validate/modify passed to the bean data and then call abstract setter.
  4. In my experience, its poor design to actually validate within the EJB Code. I typically have the following structure.Even with the use of local objects(ejbinterfaces ect)-you still have overhead associated with using ejb objects instead of regulard objects. Here is our structure-

    Web Request----->Servlet-getParametersForFields---->populate data transfer object(DTO)which is serializable---->validate against a validation class(which encapsulates all of the validation logic)-on the DTO class-----
    if everything validates------>create EJB.

    I use the reflection API to recursively call all of the DTO's get methods and validate against the validation class. I then use my own exception objects- which can be thrown during the validation phase. I think that having the validation logic in the EJB causes tight coupling. If I make a change to my validation logic, I don't have to redeploy the the EJB code to do so. Also, encapsulating validation logic causes a more modular design that makes the classes much cleaner(ie. EJB's are for data access, DTO's can be used for alot of different things, and the validation class is only for validation.) There are alot of people that'll say that validation is the job of the EJB object- but I don't see why its that desireable. I know that my validation rules WILL change- for example when we implemented one of our U.S. systems in Canada- validation on zip codes changed significantly- I used the same EJB's- and just changed the validation logic in the validation class. I didn't need to worry about redeploying a bunch of beans- instead just some regular old classes.
  5. Ahh there is the crux of the matter. I want the validation in bothe the DTO and the EJB. The idea is to make sure no object can get out of synch with what is in the database. Validating in the session bean is a bit like givign the keys to the trash man.

    How do I do the non-abstract method validation to in the ejb?
  6. The responsibility of the CMP entity bean is to store the data. The responsibility of the business logic is to validate the data. The less you mingle these responsibilities, the better.

    If you are concerned about someone bypassing the business logic and trying to store more than 30 characters using the CMP entity bean directly, then talk to the developer, rather than try to write code to solve the problem.

    Sometimes it's not a code problem; it's a people problem.

    Good luck.
  7. Actually, accordign to Object Oriented Engineering principles, an object should validate its own data. In fact it would be wasteful if everyone using a data object attempted to validate the data independently. It would also be an application hole you could drive a truck through.

    Additionally, you may not have control over the developer usign your bean. Instead of spending hours at a customer site trying to figure out what they screwed up, my beans that I sell them should catch their mistakes.

    All of this adds up to the entity bean performing data validation checks.

    What I would like to know is how I use the non abstract methods in an CMP 2.0 entity bean to validate data. A quick example or reference to a document would suffice.
  8. From a conceptual standpoint, an object should validate itself, however, there are different level's and types of validation. Making a blanket statement that "Object's need to validate themselves and all of the validation code needs to exist in the object" ignores this fact. There is business domain validation(ie. do a range check on account numbers from the General Ledger module) and there is object state validation(validate that the account number's not null ). To combine the data model with the business logic layer of the application is poor design. The data model should not need to know what the validation is in the business logic area. The business logic should not have to know how the object's are persisted to the database. What I'm talking about is loose coupling. "Coupling describes the strength of the association established by a connection from one module to another. Strong coupling results in a system that is harder to understand, change or correct." Object Oriented Analysis and Design- Booch.
    Ask yourself if including this validation logic is part of the business domain, or is it validating simply the object's state. Look hard at how easy it'll be to change your CMP objects- because you know at sometime requirements/needs will change. I wouldn't base my descision on a developer that doesn't know how to implement your system.
  9. Yes, that is self evident. I assumed people knew that I was talkign about data validation and not imposemento f business rules. Validating types, sizes, and basic requirements of data should be the domain of the data object which should correspond directly with the database validation insomuch as it is possible. This prevents data corruption from leaking into the system by providing multiple firewalls of verification. If your entity beans validate and your DTOs validate then there will be less of a problem.

    In the end, I asked a question that I am not sure there is an acceptible answer to. One of the reasons I tend to favor JDO over Entity beans is the fact that JDO does not impose abstract restrictions on the type of data object, nor does it prevent me from validating data or doign other logic inside the data object.

    CMP 2.0 with its lack of dynamic "finders" and its rigid structure makes a questionable platform for persistence integration.
  10. I realize that an object SHOULD validate its own data, but EJBs are not your ordinary objects. They are heavyweight montrosities belonging to a sometimes-silly framework. For that reason, it is best not to get too fancy with them.

    If the bean were BMP, most people would likely suggest doing the validation in a Data Transfer Object, then calling the BMP entity bean's 'setData' method to avoid the repetitive remote calls and database updates. What makes the CMP situation any different?