Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I was hoping for some advice:

I need to design a software solution for a medium-sized java / Swing application.

The application will have about 200 use cases requiring complex data validation and business logic.

Typically, this is my usual design:

  • Create a simple POJO for each use case, with a custom constructor and custom validation and business logic within it's execute method. These Operations implment simple and complex data validation such as required fields, unique names and more complex constraints.
  • Create a single controller that has a method for every use case. Each method takes custom parameters, constructs and executes it's related operation.
  • For the sake of simplicity, I won't mention details about Data Model notification or Operation queuing mechanism.

This solution has worked will in the past because it encourages all developers to reuse existing controller methods and validation, however:

The new application will use dialogs extensively for data entry;

These dialogs are expected to implement the same complex data validation and business logic that the controller implements, however the dialogs are not expected to update the data model until the OK button is clicked.

I hate the idea of writing multiple versions of the same complex validation and business logic, due to the maintenance nightmare it invites.

How can I perform complex business logic and validation for both standard data model changes and "pending" dialog changes, given that the dialog doesn't commit it's changes until the OK button is clicked?

The data model may be quite large, so creating an in-memory clone of it and the controller doesn't seem viable.

Does anyone have any suggestions? If so, I'll be forever in your debt.

share|improve this question
1  
Create separate validation classes that take the instance to be validated in their constructor and return or fill (a list of) errors. Have some sort of DI to get the validator instance for a given class(type) and/or other arguments needed to identify the use case. If needed, have a validator class that can contain other validators so each validator can be very specific and narrow in scope, while allowing complex validation to be built up from the simple ones. Now you have a validation framework that can be used both ends, and can even be configured differently on both ends if you want/need to. –  Marjan Venema Dec 11 '13 at 12:52
    
Validation implies auto-correction? Data in these dialogs is not isolated? –  Shadows In Rain Dec 12 '13 at 9:44
add comment

2 Answers

I refrain from including validation in my data model objects. I make them very simple POJOs that don't have any knowledge about the content of the values, business logic that drives them, and the state of the application.

I've create verification classes that are separate from both the controller and the data model. These are used during the import of data, and the UI that does conditional highlighting based on the validity of inputs. I make the background of a cell table light-red when the data in it doesn't match expected inputs. It's a simple matter of having a series of classes that are capable of verifying different inputs, and then, on construction, associating them with the proper input fields / cells. They're very straight forward, and dead simple to use during a data import. Mind you, during data import, I only log errors in expected data, and then allow the user to modify the incorrect data. I could easily have chosen to reject the import altogether.

Hope this helps.

share|improve this answer
add comment

I design my models so they don't easily get themselves into an invalid state to begin with. Then when my Interface (UI, or service), attempts to put it into such a state, an error is thrown which I can then send back to the offending source.

Most of the time this means that my models have a method called isValid(), that checks itself for things that can't be checked via setter. This method also handles more complex business logic that encompasses more of the model.

Validations that get repeated in multiple places I abstract out into utility functions xor validation classes so I don't have to copy-and-paste my validations. Sometimes I end up having to write a more complex service type validation, but that's fairly rare.

This makes my models fairly thick, however, I know that wherever I use that model, the validation is brought along with it. Keeping your validation separate, means always having to remember to do the validation, which can lead to programmer errors. This also tends to makes my interface (UI, SOAP, JSON etc) thinner, since it focuses on converting from the input to the model, and responding to the model changes, including validation errors.

In UI Interfaces, I'll do some basic checking of types, ranges and the like, before sending data to the model residing on a server. In some cases, where performance dictates I'll move some validation to the UI, but only as performance dictates.

This doesn't mean my models are monolithic either. I break my validations down into composable separate pieces that I call inside my model. It just means that the validations themselves are hidden from the model user.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.