4 ms·

> Model-View-Controller-Service-Repository Where would you put validation logic, though? I mean, some of it might need to just check whether a domain object ha

> Model-View-Controller-Service-Repository Where would you put validation logic, though? I mean, some of it might need to just check whether a domain object has its fields filled out, but other validations might need to cross reference DB data to make sure that everything is valid in accordance to the business rules. Ergo, we might have Model-View-Controller-Service-Repository-Validator Even without being silly, it's interesting to see how different languages and frameworks handle common concerns, for example, with some you will have repositories, with other the model objects themselves will handle queries through some ORM.

pravus 3y ago
Validation logic needs to be spread throughout the system because your validations are all context sensitive to the operations being performed. It's not always possible to front-load that into a simple schema in your transports and each component needs to be correct in its own domain.
- KronisLV 3y ago
  > Validation logic needs to be spread throughout the system because your validations are all context sensitive to the operations being performed. While it certainly isn't always possible, I've definitely seen it be aggregated in a single place in monolithic codebases that focused on CRUD. Essentially, it was structured like so: +--------------+ +------------------------+ +-------------+ |Resource (API)|---|Service (business logic)|---|DB Repository| +--------------+ +------------------------- +-------------+ | \ +-----------------------+ \ +-----------------+ |Validator (validations)| \|REST clients etc.| +-----------------------+ +-----------------+ The Resources were typically just API endpoints (HTTP), that passed data onwards to Services. Those could then call upon other services or service requests on their own: store/persist data with Repositories, deal with scheduled processes, or pass data on to other systems through REST clients etc. Before Services did any of those, they reached out to a Validator to make sure that the data matches the business rules and constraints. Sometimes there was additional validation context passed in (essentially a map and some enums), sometimes there were certain constraints that an entity needed to always follow within the context of the business and so on. In practice, it was good because you could see all of the constraints in one place, that an entity has to match before it can be persisted in the DB, or passed onwards to another system. But then again, that's not always viable in more modern architectures. Of course, it wasn't the most traditional approach to MVC either, even if those concepts translate pretty well to it.
cies 3y ago
Most MVC frameworks have some soft or form DTO notion, as a form does not map 1-on-1 to one db record. The form DTOs in our app also holds the logic to validate itself. Basically, like sibling post mentioned: you put it where it makes sense. Doing validation on db entities, is certainly not a place it makes sense (except in the most trivial cases, hence the common mistake).

pravus 3y ago

Validation logic needs to be spread throughout the system because your validations are all context sensitive to the operations being performed. It's not always possible to front-load that into a simple schema in your transports and each component needs to be correct in its own domain.

KronisLV 3y ago
> Validation logic needs to be spread throughout the system because your validations are all context sensitive to the operations being performed. While it certainly isn't always possible, I've definitely seen it be aggregated in a single place in monolithic codebases that focused on CRUD. Essentially, it was structured like so: +--------------+ +------------------------+ +-------------+ |Resource (API)|---|Service (business logic)|---|DB Repository| +--------------+ +------------------------- +-------------+ | \ +-----------------------+ \ +-----------------+ |Validator (validations)| \|REST clients etc.| +-----------------------+ +-----------------+ The Resources were typically just API endpoints (HTTP), that passed data onwards to Services. Those could then call upon other services or service requests on their own: store/persist data with Repositories, deal with scheduled processes, or pass data on to other systems through REST clients etc. Before Services did any of those, they reached out to a Validator to make sure that the data matches the business rules and constraints. Sometimes there was additional validation context passed in (essentially a map and some enums), sometimes there were certain constraints that an entity needed to always follow within the context of the business and so on. In practice, it was good because you could see all of the constraints in one place, that an entity has to match before it can be persisted in the DB, or passed onwards to another system. But then again, that's not always viable in more modern architectures. Of course, it wasn't the most traditional approach to MVC either, even if those concepts translate pretty well to it.

cies 3y ago

Most MVC frameworks have some soft or form DTO notion, as a form does not map 1-on-1 to one db record. The form DTOs in our app also holds the logic to validate itself. Basically, like sibling post mentioned: you put it where it makes sense. Doing validation on db entities, is certainly not a place it makes sense (except in the most trivial cases, hence the common mistake).