Design Patterns

Architectural guide to unify business rule and input pattern validation without compromising on code readability

In ISCP we started validating requests with ServiceStack Fluent Validation (about five years ago). This was limited to pure input pattern validation (let's call it field validation) with no regards to correctness of the same in relation to the data in the database (business validation). The latter was done inside service method (if required). Later we introduced a service-agnostic manager layer and moved logic from service methods to managers. At managers we opted to creating separate validator types to offload business validation logic from manager methods for readability purposes.

Continue reading

Applying template method design pattern

Recently I worked on refactoring a piece of code which dealt with filtering DB entities based on certain attributes and there were different types of such filters each doing almost the same thing and the problem was, how to reuse the common logic while making sure that the specific details of filtering are the only thing each filter will have to worry about. To better explain the problem and its solution, consider an example of a banking system, different entities in the system are the client (the account holder), account, deposit, withdrawal, investment, investment sale, etc.

Continue reading