EntityFramework Field Driven design Practice (10): Statute (Specification) mode

I did not want to include this article in this series because it was a conceptual thing, theoretically speaking, and EntityFramework seems to have nothing to do with the discussion of the Statute pattern. But at the request of the vast number of netizens, I decided to discuss the statute pattern here, and to introduce a protocol model specifically for the. NET Framework.

Most of the time, we'll see a design similar to the following:

A design of customer warehousing

public　interface　ICustomerRespository
　 {
　　 Customer　GetByName(string　name);
　　 Customer　GetByUserName(string　userName);
　　 IList<Customer>　GetAllRetired();
}

The next step is to implement this interface and implement the methods in the interface separately in the class. Obviously, in this interface, customer warehousing has done three operations: obtaining customer information by name, obtaining customer information through a username, and obtaining information about all currently retired customers. One of the benefits of such a design is that it is easy to see what functionality the customer warehousing provides. This design is especially true for documented development methods.

Or the words, should be changed. If your system is simple and unlikely to expand in the future, this design is simple and efficient. But if you are designing a medium and large system, the following questions will confuse you:

Is this design easy to expand? Future need to add new query logic, resulting in a lot of related code to be modified, how to do?

Over time, this interface will become larger and bigger, and you'll be a hammer in the team. I modified the interface with a stick, and finally the whole design became a mess.

Getbyname and Getbyusername are OK because of the semantic glance. But what about getallretired? What is retirement? Retirement is more than the legal retirement age, so is the bingtui in it? All of the customers returned here include only retired male customers, or are all gender clients in it?

The protocol pattern is a special mode that DDD introduces to solve these problems. A specification is a Boolean assertion that describes whether a given object satisfies the semantics of the current contract. In the classical implementation of the protocol pattern, there is only one method for the specification class, that is Issatisifedby (object), as follows:

Protocol

public　class　Specification
　 {
　　 public　virtual　bool　IsSatisifedBy(object　obj)
　　 {
　　　　 return　true;
　　 }
}