"MVC extension Framework and Di" For an interface-extensible framework

"MVC extension Framework and Di" For an interface-extensible framework

The title "MVC Extension Framework and Di" a bit around the mouth, I also can not think of a good name, because this content is very miscellaneous, involving multiple modules, but in the daily development and inseparable

First of all, the MVC extension framework, the MVC extension, migrates the previous MVC Partition extension framework and optimizes the integration

First, the MVC extension framework main functions:

1. Mvc's Dependency Injection (DI) function (class mvcdependency)

Relies on the Icontainerfactory interface and no longer relies on specific containers

2. MVC Global Filter (Globalfilterprovider)

Configuration can be automatically called by MVC in the Dependency injection container of MVC. In fact, the logic is very simple, is to inherit the Ifilterprovider interface, exposing the filters property externally, need to increase the filter is configured in the filters attribute

3, sub-module (area zoning) development support

Area base classes and related support classes (Arearoute, Arealistservice)

4. Partition filter (Areaglobalfilterprovider)

5. Partition registered HttpModule (areamergemodule)

Use this httpmodule to initialize partition and partition Dependency injection container configuration

Second, Dependency injection (DI) is also quite complex

1. Mvc Dependency Injection (DI) support

MVC uses the Idependencyresolver interface to define dependency injection, implement the interface, and override the MVC default di configuration, mainly by adapting the dependency injection of MVC to the container to support it in order to use a container to do

2, the container of Dependency injection (DI)

Mature containers support Dependency Injection functionality, construct objects for users, and recursively perform dependency injection operations by dependency injection configuration of the current object (class)

3. Framework's Dependency Injection (DI) extension (fang.di)

One, the framework does not rely on any mature container, so in order to facilitate better use of Di technology, DI support is extended so that any container function can use the DI

Second, the DI Configuration (labeling) of each mature container is inconsistent, resulting in code that uses a specific container of Di written to the team reuse of other container technology is not good

Third, this framework supports "fast retrieval of Black technology" (refer to the core container), using this dependency injection (DI) extension can use the "Fast Search Black Technology" syntax to define the dependency injection tag

This article covers the MVC Extension Framework sub-module, the "Dependency injection (DI) extension" submodule, the core container of the main framework, and the external mature container (This article continues to use the Unity container as an example of an external mature container)

The introduction of the almost, first, the example

First, the MVC Dependency Injection (DI)

1. Use Unity container to do di

1.1 Configuration initialization

First inject the Unity container, initialize the MVC dependency configuration (instead of the MVC default Dependencyresolver)

1.2 Build a test page and use unity to configure a dependency injection service

Ok, Dependency Injection succeeded

1.3 Look at the Unity container configuration

2, use fluent code to do dependency injection

Wood has problems, effects come out. Using container technology is not necessarily a configuration file, and the fluent method is also one of the options for configuring the container. Of course, the configuration file with fluent is also a wood problem.

While the above example is simple, there are many techniques available, with the MVC extension Framework, the Unity container, and the Dependency injection (DI) extension.

Second, global filter

1, filter code is very simple

The above is just actionfilter example, MVC support Authorizationfilter\exceptionfilter\actionfilter\resultfilter can be configured like this, is not very cool AH

2. Take a look at the container configuration information

Some people say, can you use the fluent code to make another example of filter? Of course, just create a Ifilterprovider object and inject it into the container. There is no need to do this repetitive work again.

I am very recommended to use the configuration file, the project and the invocation of the service specific implementation class can be completely isolated, in order to better reflect the role of the IOC container

Three, sub-module (area partition)

1. Partition Routing Configuration

2, two partition configuration

3. Execution effect

The results of the above two partitions are running, and the services that are called by two partitions are slightly different, resulting in slightly different results

section of the explanation does not expand, see the original article "Partition extension framework", but the partition filter is slightly different, then explain the partition filter

Four, partition filter

1, or use the global filter code, directly see the results

The above is actually the partition filter and the Global filter integration test, two partitions share a global filter globaltest, each partition also has its own partition filter, the effect is good

2, look at the filter configuration (configuration and global filters are different)

Look at the above configuration, the partition filter and the global filter configuration almost consistent (actually is also an inheritance relationship), and split out from the partition, the effect and original (see the original article "Partition extension framework"), the structure is not much clearer, but also reduce the burden of area initialization, is optimized.

3, Areamergemodule (partition registered HttpModule) configuration

Configuration method is still so simple, this aspect of the content is still refer to the previous article

V. Framework's dependency injection (DI) extension (fang.di)

1, Configuration method

and Unity's attribute dependency injection similarity is very high, but the namespace is not the same, but much more useful, but also to the container does not support Di (dependency injection)

2. Execution effect

The effect is the same as the Unity container configuration. Using the DI extension can be used to unify the dependency injection syntax for different containers. But in the ointment, I only implemented attribute dependency injection in the Dependency Injection extension Module (FANG.DI).

This extension di does not overwrite the original container (such as Unity) Di, but also detects whether Di's properties have been initialized (!=null), which means that the extended Di is complementary, the original container di succeeds no more di, can also be used at the same time (if you are not too confused)

I personally think that it is sufficient to have the attribute dependency injection. Of course, many people have a reason to refute, the most critical should be security. If we give the service initialization to the container, do not modify the service object, there is no security to say, if you want to modify, even if it is private, the class can also be modified, external use of reflection can also be modified, there is no absolute security.

3. Use "Quick Search Black Tech" syntax to define dependency injection tags

The emphasis in the above note is to see a point (.), in this case, the default time format service in the Global service container di to the properties of the current controller, that is, any container can be any service di come over, absolute black technology!!!

Vi. How the functional modules work together

1. Mvc extension Framework, Unity container and Dependency Injection (DI) extension modules are independent of each other and are not dependent on each other

It is clear that they are independent of each other, but they are all dependent on the interface-oriented main framework (Fang.framework), and the main frame is very important, the relationship between the respective and the main frame is very important

(This is why I designed this framework, to add more features later, or to introduce more third-party components, all rely on the main framework, are the main framework of the service (plug-ins) or MVC and other MS Framework plug-in call to run)

2. How each module works in the above example

See project configuration First

The above first registers the Unity container, then registers the dependency injection extension (FANG.DI), and the partition and its routing rules use HttpModule injection

We also saw an interesting thing to initialize the di incredibly similar to initializing the Unity container, in fact, the di extension is the container encapsulation, which is plainly the container extension, that is, I am through the expansion of the container to implement DI

3. Let's see how Dependency Injection Extensions (FANG.DI) work.

3.1 Dependency Injection Extension (FANG.DI) project

A:dependencyattribute is the Dependency injection callout (Attribute), which is labeled by the attribute that needs to be injected

B:container and Containerfactory are container packages, and the encapsulated container object has an expanded Di function, so the original container we call has a dependency injection function in this package even without the dependency injection function.

The C:propertychecker class is responsible for finding those attributes that require dependency injection, and the Propertychecker instance object encapsulates a property of the dependency injection process (function)

D:checkcontainer defines an interface (Icheckcontainer) that uses a container to handle dependency injection and multiple checkers properties that contain multiple Icheckcontainer objects and implement Icheckcontainer interfaces on their own

(In fact, it is the combination of container processing Dependency injection mode, where the previous propertychecker is the implementation of the Icheckcontainer interface, generally speaking Checkcontainer object contains an array of Propertychecker)

Note: This piece just developed, Checkcontainer this name a bit of a problem, and then change, if there are suggestions good name can reply to me, thank you

3.2 Take a look at the main logic of checkcontainer (or rather simple)

READ:

A: Dictionary (concurrentdictionary) cache objects by type

B:monitorwrapper is an object lock package that I wrote to avoid deadlocks and control locks for the longest time (default 50 milliseconds) and to return whether the lock was successful;

(since it's a cache, the lock is just a tool to help us increase the cache utilization, so we continue to do it regardless of whether the lock is successful)

C: If there is no cache, we get writable and annotated (Dependencyattribute) properties by type, construct injection function (Icheckcontainer) objects by attribute

D: Here the injection is relatively simple, I use the reflex directly;

(Plan to use emit later, but my emit foundation is too poor, emit a function to half a day, later in the study emit skills or spend time good debugging, in order to performance can not have a bit sloppy)

The content of this article is finished. This article and the original "Partition extension framework" have a lot of the same place, but the essence of things very different. The original partitioning framework is strongly dependent on the Unity container, and this framework uses a container factory configured to the main framework.

Many configurations also have more customization, and the framework also takes care of the interests of development users who do not use partitioning (global filtering and Mvcdependency (DI)).

There is also the seamless integration of the Dependency Injection expansion module (FANG.DI) and the MVC extension framework. Of course, Fang.di is equally effective in non-MVC, and here is not an example of that.

Tags: interface-oriented, DI, ASP, container, Unity, MVC extension Framework

"MVC extension Framework and Di" For an interface-extensible framework