Should we implement the state machine logic near the data in the "persistence" layer, or bring the data out and implement it in the "listener" layer?

Question

The implementation is MVC. The View is isolated to the browser layer. The Model is isolated to the persistence layer. The Controller is split with: UI controls in the browser mostly so input is syntacticly correct, authentication and authorization controls are in the listener layer (Tomcat and remote LDAP), and data integrity controls in the persistence layer (an RDBMS with stored procedures).

Question is, where should the business logic control go? It is defined by a data driven model in the persistence layer. So the code/logic could go in either the persistence layer itself via stored procedure, or in the listener layer via Java classes. If it is to be in the listener, additional work will need to be done to bring the data across layers.

Possible duplicate of [Clean architecture validation in domain vs data persistence layer?](https://softwareengineering.stackexchange.com/questions/351419/clean-architecture-validation-in-domain-vs-data-persistence-layer) — John Wu, Apr 25 '18 at 00:06

score 0 · Answer 1 · answered Jan 24 '18 at 22:26

Business logic should be enforced at the first source of changing data. If you wait to apply business logic until you are "ready" to persist the data, you will create inconsistencies, and provide a very poor experience for your users.

Validation of data should be done in two ways: don't allow incorrect data to be selected or entered, and provide immediate feedback to the user when they attempt to provide bad data. Both of these are functions of how the view of your model is presented to your user for editing, and how the control of the data is applied to inputs.

Should we implement the state machine logic near the data in the "persistence" layer, or bring the data out and implement it in the "listener" layer?

1 Answers1