Announcement Announcement Module
No announcement yet.
Common validation on server, Spring RCP, and Web client? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Common validation on server, Spring RCP, and Web client?

    I'm wondering if there's a best practice for performing the same type of validation in the business logic layer as in the presentation layers (both Swing via RCP and Web). Spring has its Validator concept in org.springframework.validation, but that's different from the RulesSource/RulesProvider idea in RCP which is itself more like what Struts offers.

    Some of the validation I need to do is oriented toward required fields and field lengths, but others are logical constraints such as "you can't delete this object when it's in this state or not owned by you".

    I've toyed with just putting using the Spring Validator idea so that the API validates before create/update/delete, the Swing UI validates on each change notification, and the Web UI validates on submit. Addtionally some validation would be performed as the form is being created, e.g., don't enable the delete button if the delete validation would fail.

    Anyone care to share opinions on this with me? I'm open to anything, but if there's a recurring pattern here, especially one that leverages the existing frameworks, I'm very interested.


  • #2
    The question is where to put this into. Since you are referring to it as being business logic, it may be better to not deal with Spring RPC then. I can't help but I consider the Spring RPC as just a way to interact with a domain layer. You know for me Spring RPC is about the presentation layer (View and controller).

    The domain layer should protect itself in your case. This means you need an exception hierarchy to indicate some common reasons of failure. Also the test cases of that abuse of the domain model API should belong to the domain layer. Also your actions (Prensentation layer) need to display a dialog (or better notify the user), if the action fails (or would fail). This can be done by a special action implementation (abstract class) since the cause of failure is shared among some actions of decent kinds.

    In case of considering the validation to be about the domain layer, check out what Spring (not RPC) can do for you. I guess it should meet your requirements.


    Martin (Kersten)


    • #3
      what about the commons validation? is it possible to combine the spring rcp with commons validation? other question --> is it a good or bad idea?



      • #4
        Typically, the business layer will need to perform all validation in order to ensure data integrity (you can't always assume you will have a well behaved client calling into your service or business logic). In this case, the UI performs validation purely as an assist to the user, or to provide more immediate feedback. For example, I want my user to immediately see when they have entered an invalid value, rather than waiting for the round trip to the server, only to have the server send back an exception. With this in mind, the question becomes, is it possible to write validation rules in such a way that they can be reused by both the server and the client? On the server side, they will be used to ensure the integrity of the system, and on the client side they will be used to give immediate feedback to the user. In our rich client project, we accomplish this by using the validation rules on both the server and client side, so it is more of a class reuse solution. We are currently investigating to see if using some sort of rules engine would provide us any more benefit (drools or something along those lines). If we used a rule engine, we would have the server transmit to the client whatever rules apply to the current domain object. We would then need to integrate that rules engine with the validation system used by Spring-rich.


        • #5
          We actually did end up using the same validation logic to perform initial UI configuration. For example, we have a manager that has the methods validateForSubmit() and validateForDelete() that internally use the Spring validator framework. The manager's implementations of submit() and delete() use these to decide if the object is fit for the operation, but the UI also uses them to decide whether the submit or delete buttons should be enabled or not. For simple UI control validation such as required, max length, etc., we're using the Spring RCP Rules/Constraints. So it's a two-pronged approach, but for true business logic validation, we're successfully using the same code on the server and on the client.