Entity Validation in SessionBean or EntityBean


EJB design: Entity Validation in SessionBean or EntityBean

  1. Entity Validation in SessionBean or EntityBean (7 messages)

    We've been having quite a discussion here in our group about validation and wanted to get some 'external' thoughts.
    By validation, I am referring to the 'process' of ensuring that information (destined for an EntityBean) is semantically correct before actually storing it via an EntityBean.
    The question is: Where sould this occur? In the SessionBean or in the EntityBean? I can see arguments for both, but I have always leaned toward SessionBean because SessionBeans represent a user interaction. Plus, all client interaction should be with the SessionBean anyway.



    Related to this, since a SessionBean acts as a facade to the EntityBeans, I would assume that there are 'get' methods on a SessionBean to retrieve the EntityBean data. Is this how it others have done it?
  2. As a starting point, I think of Entity beans as OO objects. As such, the entities have invariants and the entity class should make sure these invariants hold. This is a general OO practice which is very important, and it holds for entity beans as well. If you rely on a session bean to do all the validation, you break the modularization of the code, create dependencies, and effectively eliminate reuse.
    Of course, invariants can be maintained in many ways. One option is to allow state modification using a value-object, and put the validation code in the value-object. This way, the entity does not have to check the invariants - they are guaranteed to hold for the value-object. If you use this approach you also get the advantage of early validation, i.e not having to go all the way to the App server tier to realize something is wrong.

    I think the only type of validation that should be done in session beans (playing the facade role) is business logic rules. Business data rules are more conviniently maintained in an entity-bean/value-object. Business data is often shared by seperate applications, and the very definition of the "business data" is that it complies to certain constraints which are independent of the particular application. If it was dependent of the application (as would be the case when you place validation logic in sessions), different applications couldn't share it as a general business data model.

    This seems to me like a very clear cut seperation. I would like to hear some arguments for the other way - I can't think of any.

  3. Gal,

    I would have to agree with you. As data objects are essentially an abstraction of the data layer, all data based validation and modifications should be at the entity bean level.

    Throwing such validation into Session Beans introduces a logical bind between business logic and data logic essentially destroying, the principles behind data abstraction and layer abstraction.

    This basic premise extends back to the core development principles in OOP, for example imagine a field changes from length 10 to 20, if the validation is at the entity bean level validating the length of this field, then simply when the change is made to the schema the change can then also be made to the entity bean, but if it is put in numerous session beans imagine the hassle associated with locating and isolating such validation. Which also reiterates the benefits of code re-use.

  4. I understand what you are saying, and it appears that there are 2 different kinds of validation: data and business.
    I completely agree that the data validation belongs at the EntityBean layer. To me, these validations are just like you mentioned: lengths, data inter-relationships, etc.
    My original question was more focused on the business-type validations. I think these type of validations belong in the SessionBean, although they often operation on only one Entity (and in other cases multiple Entities). Some of these rules are simple, like is the effective date of membership less than 6 months in the future, and others are quite complex, like checking the past history of a Member. Simple or complex, I think that these business-type validations belong on the Session and would like to hear where others are putting these types of 'rules'.

  5. Mike,

    Sorry when I read your initial point, I assumed the use of the work 'semantic' meant pure data validation. But having clarrified your comments, business validation should indeed be at the session level. I recommend introducing a special class of SessionBeans dedicated to the purpose of validation, which is along the lines of what we've done here which makes sense for us of course, it may not in your implementation.

  6. Obviously, when the rules you need to inforce are business rules that are only related to one specific application of the data, they don't belong in the entity bean - which is not dependent of any specific application.
    My original point was that these rules should not be validated in an entity bean. In the specific design where session beans play the role of an MVC controller, such rules should be validated in these session beans.

    Again, I still can't really see your point. As I see it, this sort of validation simply can't be performed in entity beans, or it would become the business-data definition (and the rules we are talknig about aren't!).
    IMHO, the only problem is deciding what is your business-data definition, and what are your specific application rules. This may be hard if you only have one application to start off with. However, I think this is a case-by-case question and there is no way it can be "generally" discussed here (without having the specific details).

  7. Well i would caution you not to use the Session Facade to do any valadation. The purpose of the pattern is to provide a local interface to entity beans, there for it is to spead up applications.

    Having said that, I believe what you really are saying is you want to have a session bean do validation and pass the information to an entity bean (lets dont use the pattern session facade in this discussion.) I would agree with one of the above responses in that, data valadation is not the responsibility of the session but the business object you are modeling. The business object is the EJB, so if the EJB expects certain data and rules have to be followed it should make sure that they are ..... now i astrix that with the following, it may sometimes be important to have a session bean cordinate the business validation of several entity beans.

    If you simply use entity beans to store and retrieve data, then you are only increasing your response time with out any good reasons.

  8. I would say, if the 'validation' is related to a specific business process, like say, checking a 'discount amount' field against a rule like "Customer eligible for discount if length of custom > X months and product value exceeds $X", this is part of the business logic and should be in a session bean.

    However, if perhaps there is some business logic intrinsic to the entity, like perhaps, "If customer is of type X then must have email address" , I would put that in the Value Object (not really in the Entity Bean itself). That way it is easy to catch this error by the exception the value object throws at the client side rather than having to round-trip to the server and back to deal with it, as stated above by someone.

    The rule I would use is, if the valildation involves more than one entity and especially if it involves a process-specific state then it is part of the business logic and should be in a session bean. Not necessarily the facade, but in the session bean which implements the business processes. If it's just a single entity even if it involves cross-checking fields of that one entity then I would put it in the value object.