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.
2
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.
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.
You have a domain model that encapsulates validation and business logic, and that is no bad thing.
Consider what ‘hexagonal’ architecture would imply for your design. Specifically, it would recommend that you design an interface to your persistence layer, allowing different persistence mechanisms to be plugged in as adapters.
When performing the business logic for real, use the database adapter.
When running the business logic for a dummy run, to check the validation rules, use a dummy adapter that does not write back to the database, just gives an OK if it gets that far, or drops out with some validation exception if it does not.
Now your domain model can be used in both situations, allowing you to re-use the code.