The core container for the ASP. NET Interface Framework

The container part of the new frame has finally been tuned! Containers are really important, all using a noun called "core container".

Why are containers so important? It needs to be said.

1, first of all we say from the framework name-oriented interface programming speaking, what is interface-oriented programming? (This degree Niang answer a bit)

READ: A class is the definition of an individual (modeling), and each aspect of an individual can be an interface

White point, one interface can represent an aspect of an object (class), and again the point object may be a generalist (inherited interface), able to work in different scenarios (as instances of different interfaces)

Second, each interface can be different implementation, as long as the implementation of this interface, basically can replace this location to work properly

2, I think interface-oriented programming is essentially object-oriented programming

We need a large object library to support the needs of the system, but also for each location of the object to facilitate "at any time" to replace, expand

So how do we manage this huge library of objects, and how do we orchestrate it for management? Here is the container, the container can be very good for the job.

3, the role of the container

I think the container is the warehouse, is the cupboard, is the box, so that we like the way we store their own objects, the following need to be able to find them conveniently

A good container can also maintain object creation, lifecycle, interception method Execution (AOP), etc.

There's too much crap in front, the usual, first example.

I. Creation and management of objects is the responsibility of the container

1, the following is an example of the context of the previous article, the use of containers to simplify the following code

The above code is not simple and beautiful much

2, the code is simple, the function is no moisture oh, look at the following implementation results

is not the same as the result of the previous article.

3, the result is not anything, change a configuration (do not change the code), a change of results try

4, then change the configuration (or not code)

This time vivid, the family each has each individuality, is not very dazzling ah.

5, we look at the configuration

Discerning eye can see this is the configuration of the Unity container at a glance; some say, aren't you relying on unity containers? I swear I didn't rely on unity containers, but I didn't say I didn't have unity. I'm just going to make a framework, and other technical solutions can be integrated, as well as containers.

You know unity with unity, you are familiar with spring.net can also be used with ease, as long as you encapsulate and integrate the framework of the container interface, and registered in

Second, using unity containers, but not relying on unity container

1, the place to call the container is not dependent on unity

This test project, in addition to a few references to the system, only refers to the main frame.

2. The main frame does not reference unity container

You're not kidding, are you? There is no reliance on unity, and even the main framework has no dependencies (referencing) on any third-party components except for a few simple system references, but this does not affect my use of a large number of third-party libraries, because this is the "interface-oriented framework"

is not now again on the interface has a further understanding, is not "interface-oriented framework" the name is a bit of a veritable.

Three, the following to decrypt how he actually run

1, look at the portal, see the application (here is the console program) reference

Haha, is not found, here finally see Unity quoted

But don't be fooled by appearances, in fact the main character here is fang.unity, because this project can not directly refer to unity container, Fang.unity is the package of unity container.

The console program for unity-related DLLs is run-time dependent, not compiled dependencies, where direct reference is easy to debug

2, continue to explore the principle

Fang.unity not always run automatically, right? Of course not, on the code

There is a very insignificant, but very important line of code "Fang.Unity.ContainerFactory.Init ()", he is "the culprit"

In other words, the Unity container is completely run as a plug-in in this framework, and if I don't call Unity's init, call Spring.net's Init, that's where the Spring.net container is now.

Some people say this is too inconvenient, of course, not every time the use of the container to be called, if the Web project can be called in the global Application_Start is OK, can also be called in the HttpModule init.

Most of the time we use containers extensively in development, but don't think about what containers I use specifically.

In other words, I am familiar with the Unity container, I use the Unity container configuration debugging through the components for you to use, but you always use spring.net (or other containers), you call the Spring.net container package, the configuration modified to spring.net configuration, Code to work as expected

Note: As long as component development is supported by the framework's container, there is no direct reference to the Unity container and the code that calls the Unity container directly

3, or take a look at Fang.Unity.ContainerFactory.Init is what Ghost bar (haha, or not sleep)

Unity container does not unfold here, I will open a single article about Unity container and unity package, etc.

Iv. Core Container parsing

1. Container related Implementation class

2. The core class diagram is as follows:

A little analysis of the division of the various classes:

The A:icontainer interface is the basic function needed to define a container

B:icontainerfactory defining the Container factory interface

C:globalcontainer is a static configuration class that provides an API to register external container component functionality and provide a call container

This is the key to implement the container plug-in, this implementation is referenced by the dependencyresolver of ASP.

D:simplecontainer provides a simple and default container and container factory implementation

Appcontext in the text container is his implementation, if you do not configure the extended container function, the use of the container is him, but he is actually a dictionary cache, save something, take a thing, no problem, complex configuration and Di, etc.

E:containerwrapper is a container blocking class that intercepts container operations in order to add features and functionality

After this, there is a very interesting feature.

F:containerfactorycachewrapper is a container factory package and cache

That is, outside the container factory is not to consider the single-mode cache what, he arranged, and the production of each good container object inspection and packaging good

It's too late, just write it down here.

The core container for the ASP. NET Interface Framework