Limitations with Persistance-layer-only validations (DRY) about northwindtraders HOT 5 CLOSED

also the same validation rules are repeated twice in the application layer command handlers, once for create and once for update, so you would end up with repeating the same rules 4 times throughout the solution

from northwindtraders.

I found this article which gave me some ideas on handling this situation.

https://hackernoon.com/mediatr-behaviors-to-validate-api-resource-existence-f81182e8a36c

from northwindtraders.

I actually ended up using the override Validate found here.

https://stackoverflow.com/questions/13198471/fluentvalidation-multiple-validators

from northwindtraders.

Just seen the Clean Architecture with ASP.NET Core 2.1 talk and it was great, thanks for all of this hard work!

Hello and thank you. :)

What if i want to render a widget in the UI and want to set it's max length too? It's a really common scenario.
This is why I've always had validations in a layer up both persistance and validation. I see how data annotations in the domain entities would fix this but since it's discouraged by the talk. What would be the best approach to tackle this? Maybe define fluent validation rules at the application layer and somehow retrieve those rules both in presentation and persistance?

In this design, data annotations at the domain layer will not support validation at the application layer. Recall that we are validating the queries and commands, and not the entities. In fact, the entities will not be exposed to the client through the Web API or any other mechanism. They will remain internal to the solution.

I use Fluent Validation, because it supports both simple and complex validation scenarios. This integrates well with ModalState and supports unobtrusive validation.

One thing that I need to investigate is how well Fluent Validation works with Open API. I've heard that data annotations provide a good experience with Open API, such as supporting max lengths and so on.

Remember that you can always push your validation down to the domain layer, and this will avoid duplication such as in the create / update customer scenario.

Thanks @paulgbrown for your suggestions. The articles seem useful.

This area is certainly something that warrants further exploration.

Again, great talk! ^_^

Thanks again and happy coding!

from northwindtraders.

Just a heads up, I've added this to the road map - https://github.com/JasonGT/NorthwindTraders/projects/1#card-17415138

from northwindtraders.