

We had to cut a little scope at the end of the project, and that was a feature that was dropped. We're not utilizing the Precision and Scale, but we had planned to.
#WINFORMS ERRORPROVIDER SIZE HOW TO#
When I started creating my MVP pattern, I knew that I'd end up being able to leverage LLBLGen's information to drive validation, but I had no idea how to make it happen. LLBLGen offers some very powerful access to the data model definition, via the domain entities. The project at hand was using LLBLGen to generate the domain entities and the data access layer. This proved to be an excellent way to meet the standard requirements as well as the exceptional ones. But I strongly wanted to be able to override the domain's rules where necessary. When I started creating my pattern, having the validation defined by the domain entities was actually part of the ultimate goal. However, what I didn't talk about in detail was that my extended MVP pattern actually satisfies the desire to put the validation logic into the domain layer. I argued that I've seen times with having all of the validation (and all other logic) in the domain layer doesn't pan out. Specifically:Įach 'thing' in the model should include it's own business rules, validation rules, security, and persistance rules.

When I wrote my Extended MVP Pattern article back in November, it got some criticism.
