WCF from theory to Practice (from): oo great deviation

Overview

One of the less consistent aspects of WCF and traditional object-oriented programming: operational Overloading (Operation overload), this article describes another WCF that is less OO-compliant: The inheritance relationship between service contracts and data contracts. There are two principles in the large object-oriented principle

1) Dependency Inversion principle

2) Liskov Replacement principle

The dependency inversion principle emphasizes that implementation relies on abstraction, that abstraction does not depend on implementation, and that the Liskov principle emphasizes that subclasses must be able to replace their base classes, which are described in detail in Anytao << you must know .net>>. This article is not intended to elaborate the details of these two principles, to understand the principles of OO knowledge, you can read Wang's masterpiece. This article only explores the dialectical unity of these two principles under the WCF architecture.

Features of the WCF architecture

Before figuring out WCF's conflicting relationship with the two OO principles, I think it is necessary to understand the WCF architecture and understand the WCF architecture to get a clearer idea of why WCF has a dialectical relationship with these principles! Let's take a look at how WCF communications works.

Look at the WCF architecture above (the original source <<WCF service programming >> a book), from the diagram we can see that there is a clear demarcation between the WCF communication, although WCF also supports IN-PROC, but this demarcation still exists. We know that interfaces and abstract classes are abstract descriptions of the real world, and they are based on real scenes in reality. For example, a rooster can crowing, a monkey can get on a tree, a mouse can steal a hole, a rooster hen is a chicken, chickens, ducks and geese are all poultry. These are human beings in the long-term social life, the real world of a kind of understanding! There is a regional character in this understanding, for example, some areas see snakes as poisonous beasts, if the snake to make an interface, it will include the following: void Eatpeople (); It eats people, it's bad, but in other areas it may be a totem, and the snakes in their eyes are sacred, If they were to describe snakes, they would say: void Protectpeople (); snakes can bless mankind! The same is true of the classification of things. Metaphor to software development, we define a boundary under the interface specification and class level for other boundaries of the system is not necessarily universal? The answer is in the negative. In WCF, the service and the customer are completely loose coupling, there is absolutely no need to understand each other's specific implementation, if not to use WCF, the two old dead can not exchange. But the two joined WCF after the contact, my understanding is that proxy is the matchmaker between the two, it played a bridge, ties, intermediary role. Since it is an intermediary, then he should be keeled, not because the server's own problems to the client caused unnecessary burden, and vice versa! In other words, the WCF service-side definition of some of the hierarchy is the specification of the server, these specifications for the client, whether it is applicable, depending on the client's specific business logic, so the agent of the matchmaker can not impose the logic of the server to the client. Let's look at two aspects of the hierarchy of service contract (SERVICECONTRACT) and Data Protocol (DATACONTRACT) to see how the WCF framework embodies these characteristics.