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.
Best Answer
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.