WCF distributed development Step-win series (6): WCF Service contract inheritance and decomposition design

In the previous section, we learned about WCF distributed development steps to win (5) service contract and Operation Overload part. Today we continue to learn about the knowledge points related to WCF service contract inheritance and service decomposition design. What are the advantages and disadvantages of WCF service contract inheritance? What are the principles and basis of contract design in actual project? What can be learned from object-oriented design experience? Here we will give a detailed description. First of all, this paper introduces some concepts of contract inheritance in WCF service, example code Analysis, and then explains the design of service contract. First of all, we introduce the necessity of service design, the principle of service design, and sample code analysis. Finally, the summary part of the full text. The structure is as follows: "1" oo object-oriented design principle, "2" Service Contract inheritance, "3" service contract decomposition concept, "4" service contract decomposition Principle, "5" Service contract decomposition Code analysis, "6" summary.

"1" object-oriented design principles OO:

It is necessary for us to review the object-oriented classical design principles first. These design principles have important reference value for the design of WCF service contract. The service contract actually uses the interface to define the implementation, the syntax is similar, the WCF framework is also based on the existing language system, which expands the programming model, such as the addition of the attribute setting mechanism. If you have ever approached Oo object-oriented concepts, these design principles will not be difficult to understand. Many programming books will be introduced, design patterns related books will have a more detailed introduction. Here are a few key concepts that pave the ground for inheriting and designing the WCF Service contract section below:

<1> Single Responsibility Principle (SRP): A class should have only one reason to cause it to change.

<2> Open Closure principle (OCP): class modules should be extensible, but not modifiable (open to extensions, closed for changes).

<3>liskov replacement principle (LSP): Subclasses must be able to replace their base classes.

<4> dependency Inversion principle (DIP): High-level modules should not rely on low-level modules, both of which should rely on abstraction. Abstractions should not depend on implementation details, and implementation details should depend on abstraction.

<5> Interface Isolation principle (ISP): Client programs should not be forced to rely on methods they do not use.