An "MVC extension framework and Di" For an interface-extensible framework of ASP.

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 in the MVC Dependency injection container can be automatically easy to use, 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, on the example

First, the MVC Dependency Injection (DI)

1, use Unity container to do MVCDI

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.

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 surface. There is no need to do this repetitive work again.

I would highly recommend the use of the configuration file, the project and the invocation of the service is 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 is not expanded, see the original article "Partition extension framework", but the partition filter is slightly different, the following to explain

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. Check the filter configuration

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, he can also use Di for containers that do not support di

2. Execution effect

The effect is the same as the Unity container configuration, so you can use different containers to unify dependency injection syntax, but in the ointment, I only implement attribute dependency injection in the Dependency injection extension (FANG.DI)

I personally think that there is a property dependency injection on the communication, of course, many people have a reason to refute, the most critical should be security, if we give the service to the initialization of the container, do not modify the service object, there is no security said; If you have to modify, even if the private use of reflection can be modified, There is no absolute security.

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

The emphasis in the above is to see a point (.), that is, any container can be any service di come over, absolute black technology!!!

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 partition framework is strongly dependent on the Unity container, and this framework is used to configure the container to the main frame.

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 the same effect in non-MVC, and here is not an example of that.

An "MVC extension framework and Di" For an interface-extensible framework of ASP.