Microsoft nlayerapp case theory and practice-infrastructure layer (cross-cutting part)

From thisArticleAt the beginning, I will gradually introduce the basic architecture layer, domain layer, application layer, and distributed service layer of nlayerapp. This article focuses on the infrastructure layer. Based on the above analysis of the nlayerapp architecture, it will contain two parts: the infrastructure layer component for processing data access and the cross-cutting infrastructure layer component. The infrastructure components used to process data access mainly include the specific implementation of warehousing,Unit of work(Poeaa, Martin Fowler) implementation, nlayerapp entity model definition, and preparation for standalone TestingService stubs(Poeaa, Martin Fowler); the infrastructure components of cross-cutting mainly include IOC (inversion of control) containers and tracking applications.ProgramThe trace tool used to execute the process. Although these are components of the infrastructure layer, they also contain a lot of technical details and even the design points. Let's give a detailed explanation of these contents.

Implementation of IOC containers in nlayerapp

In the process of application design, we will follow this design principle, that is, the association between types should depend on interfaces or abstractions, rather than specific implementations. In this way, we can easily replace the specific implementation method of components without changing the entire program structure. This not only makes the application of the service stub mode possible, this improves the system testability, decouples the dependencies between components, and reduces the maintenance cost of applications. The IOC container is an object that maintains the ing between interfaces and implementations in the application execution environment and the dependencies between implementation objects, so that when a client program sends a request to the IOC container, it can return the specific implementation corresponding to the requested interface or abstract type. The client program does not need to care about the specific implementation of the returned result, and how to initialize the specific implementation. This article does not introduce IOC much. If you are interested, you can read 《Inversion of control containers and the dependency injection patternThis article.

The implementation of IOC containers in nlayerapp depends onMicrosoft patterns & Practices unityIn fact, most applications and even development frameworks rely on third-party class libraries to implement IOC containers, because IOC itself involves a lot of content, it is not easy to solve the complex dependency between types. Unity is not the only choice for IOC. In addition to unity, spring. net, Castle Windsor, ninject, structuremap, and so on can all be a good choice for IOC containers. The classes related to IOC container implementation in the nlayerapp and Their Relationships are shown in:

In, the icontainer interface defines IOC container-related methods, it is an interface unrelated to the specific implementation technology (the layered tree of interfaces, the parameters of the methods defined in it, and the returned values do not depend on any third-party components). Therefore, theoretically, we can inherit the icontainer interface and use our own technical method to implement the IOC container. Nlayerapp uses unity as the IOC container. Therefore, the iocunitycontainer class implements the icontainer interface, and then creates an iocunitycontainer instance in a single iocfactory instance using the New Keyword:

# Region constructor // <summary> // only for Singleton pattern, remove before field init il anotation // </Summary> static iocfactory () {} iocfactory () {_ currentcontainer = new iocunitycontainer () ;}# endregion
 

Of course, this is fine for nlayerapp, a specific application case, but if we are currently designing a development framework, directly using the new keyword to create an iocunitycontainer instance will force iocfactory to depend on the iocunitycontainer type, thus violating "association should depend on interfaces or abstractions, rather than the specific implementation. In the latest apworks frameworkCodeDevelopers can select an appropriate IOC container Based on the application configuration information. For example, you can decide whether to use unity or castle Windsor when the application starts, this makes the framework more scalable. We also discussed earlier that if nlayerapp needs to inherit the icontainer interface to use our custom IOC container, we need to modify the private constructor of iocfactory, to use our own IOC container to initialize the _ currentcontainer private member.

A very practical feature of Unity containers is the concept of "root container" and "sub-container, on the "root container", you can call the createchildcontainer method to create the associated sub-container. Both the root container and sub-container can accept registration of abstract types. Every time a customer program requests a type (resolve type) from the sub-container, unity first checks whether there is any requested type in the sub-container. If yes, it directly returns the specific implementation of this type, if not, the request is forwarded to its parent container. With this feature of unity, we can manage the IOC containers in different deployment environments in a unified manner. For example, we can register the same type mappings in various deployment environments in the root container, create a sub-container for each deployment environment and register the specific type mappings related to the deployment environment in their sub-containers. Displays the basic information about the unity IOC container in the nlayerapp:

Read iocunitycontainer'sSource codeWe can understand that in the iocunitycontainer constructor, rootcontainer is created, and realappcontainer for real running environment and fakeappcontainer for single test are created on rootiner iner, the following private method is used to initialize these containers one by one:

/// <Summary> /// configure root container. register types and life time managers for unity builder process // </Summary> // <Param name = "Container"> container to configure </param> void assumerootcontainer (iunitycontainer container) {// omitted... please refer to the source code for details .} /// <summary> /// configure real container. register types and life time managers for unity builder process // </Summary> // <Param name = "Container"> container to configure </param> void assumerealcontainer (iunitycontainer container) {container. registertype <imainmoduleunitofwork, mainmoduleunitofwork> (New perexecutioncontextlifetimemanager (), new injectionconstructor ();} // <summary> // configure fake container. register types and life time managers for unity builder process // </Summary> // <Param name = "Container"> container to configure </param> void configurefakecontainer (iunitycontainer container) {// Note: Generic register type method cannot be used here, // mainmodulefakecontext cannot have implicit conversion to imainmodulecontext container. registertype (typeof (imainmoduleunitofwork), typeof (fakemainmoduleunitofwork), new perexecutioncontextlifetimemanager ());}

In the assumerootcontainer method, you have registered the types required for all environments (real runtime environment and single test environment). Then, for imainmoduleunitofwork, the actual running environment and the unit of work used in the single test environment are different: the real running environment uses mainmoduleunitofwork, while the test environment uses fakemainmoduleunitofwork. Therefore, it is also registered in the assumerealcontainer and configurefakecontainer methods.

Finally, every time icontainer. when the resolve method is called, The System reads the configuration file to determine which container should be used for parsing. Therefore, we only need to set the container name in the configuration file correctly, you can use the specified unity IOC container in the nlayerapp. The following configuration information is from the distributedservices. Deployment project. We can see that the distributed services of nlayerapp uses realappcontainer:

 
<Deleetask> <! -- Realappcontext-real container --> <! -- Fakeappcontext-fake container --> <! -- <Add key = "defaultioccontainer" value = "fakeappcontext"/> --> <add key = "defaultioccontainer" value = "realappcontext"/> </appsetiner>
 

Trace tool used in nlayerapp to track Program Execution Process

The implementation of the trace tool in nlayerapp is very simple. itracemanager is defined in the infrastructure. crosscutting project, and the specific implementation of itracemanager is defined in the infrastructure. crosscutting. netframework project. Tracemanager uses the trace-related types in the system. Diagnostics namespace to implement its functions. The application obtains the specific implementation of itracemanager through iocfactory.

In the assumerootcontainer method discussed above, nlayerapp registers the itracemanager type:

 
// Register crosscuting mappingscontainer. registertype <itracemanager, tracemanager> (New transientlifetimemanager ());
 

Therefore, you can use the following method to obtain the specific implementation of itracemanager in the entire application to complete the trace function:

Itracemanager tracemanager = iocfactory. instance. currentcontainer. Resolve <itracemanager> (); tracemanager. traceerror (/* error message */);
 

Summary

In this paper, the basic structure layer (cross-cutting part) of nlayerapp is studied and discussed. The projects related to this Part are: infrastructure. crosscutting and infrastructure. crosscutting. IOC and infrastructure. crosscutting. netframework. Next, we will continue to study the basic structure of nlayerapp (data access part ).