Description of the FACADE mode:
intention:
Provide a consistent interface for a set of interfaces in the subsystem, the FACADE mode defines a high-level interface, which makes this subsystem easier to use.
applicability:
When you want to provide a simple interface for a complex subsystem. Subsystems tend to become more complicated because of continuous evolution. Most mode uses more smaller classes. This makes the subsystem more reusability, and it is more easier to customize the subsystem, but this also brings some difficulties to those users who do not need to customize subsystems. FACADE provides a simple default view that is enough for most users, and those users who need more customizable can cross the FACADE layer.
There is a lot of dependence between the client program and the abstract class. Introducing FACADE to separate this subsystem from customers, and other subsystems, can increase the independence and portability of the subsystem.
When you need to build a subsystem of a hierarchy, use the FACADE mode to define the entry points in the subsystem. If the subsystem is interdependent, you can make them communications with FACADE, which simplifies the dependence between them.
Structural map:
to sum up:
In practical applications, it is indeed a complicated business logic. The result of business logic is bound to cause business logic layers being extremely complicated. Complex business logic layers are not only too complicated and easily erroneous. And its complexity will also affect the modification and maintenance of the business logic layer. Microsoft Duwamish sample code introduces Facade ideas to solve such a problem.
Microsoft's approach is to separate the business logic layer, establish a FACADE layer and rule layer, respectively. Some elemental business logic rules are encapsulated by the Rule layer, while the FACADE layer has played a view and controller. Requests from the web cannot access the Rule layer directly, but must access the FACADE layer, by the FACADE layer to the requesting decision to access the rule layer or the data layer. In fact, the FACADE layer is the abstract business logic on the basis of the Rule layer, and there is a logical logic of the specific appearance, and the image is established. When the web layer issues a request, the FACADE layer first determines the requested content, if it can process it directly, then call the data layer directly. If its own business logic is not enough, the RULE layer is accessed, and the data layer is accessed by the Rule layer.
In fact, this method of facade is that the abstraction of a complex system in portrait is to modularize complex systems, thereby reducing the complexity of each module. When I think it will have a limit, sometimes it may not be able to carry out enough portrait abstraction. You can not perform horizontally abstraction to the system, directly to the business logic abstraction as several modules, then write a total service logic call layer, directly call the business logic module, thereby implementing abstraction. I think this design should not be difficult, combine vertical and horizontal abstraction, I believe a logical layer that is designed can be more useful. Maybe, there is no trial, I don't know if I will encounter.
