The application context scope component of ASP. NET-oriented interface framework

In the team to promote interface development for two years or so, the results generally I am quite satisfied with the interface development of the module using the Unity container configuration is very stable and good extension.

But because of the rush of development at the time (side development side application), left some more deadly problems:

1, many interface definitions unreasonable, universality and extensibility is not good

2, Fixed dead Use Unity container, if a larger area to promote the problem, some people are already familiar with other containers, and then to re-learn unity is not necessary

3, the configuration is more troublesome, need to simplify

So I think it is necessary to re-develop a framework, the original framework to take its essence to its dross, and then absorb open source projects (including Microsoft Open Source parts), to make a decent thing and open source out ...

Here, in front of a write an ASP. NET MVC Partition extension framework is not finished, one is to hurry to do this framework, and the other is to re-make the new framework, all the rest of the article according to the new framework to write will be better

Here is a small component of this framework, the application context component (AppContext), this component has a reference to the blog Garden article, here first not to indicate the source (if the author of the article Mind, I revise the post callout)

The main usage scenarios for this component are described below

1. New ways to transfer data between different objects and methods, see examples

Look at the results of the operation:

Someone would say, you do it, modify the A method to return that random number, modify the B method to add a parameter to accept this random number, so easy.

But adding a subordinate function to the existing completion architecture would be a horrible thing to change the signature. The actual project produces object methods and other methods that need to call the object may not have a call chain, or the call chain is not complex, you have to change all the methods involved, the system is estimated to be changed by you to "waste"

The above code runs as expected, seemingly simple functions, the latter principle is still quite complex

2. Thread-Safe invocation

The above uses two threads to read and write data to the context, to see if the data will be string (thread is safe), see the execution result:

Read it a little bit:

A: Thread 6 runs first, reads the key from the context string value is empty, blocks 1000 milliseconds, writes the key to test, the type is a value of string 1000, and then blocks 1000 milliseconds

B: Thread 11 reads the value from the context of the key to test type string is empty, blocks 14 milliseconds, writes the key to test, the value of type string is 14, and then blocks 14 milliseconds

C: Thread 11 reads the key from context to test type string with a value of 14

D: Thread 6 reads the value of a string with a key of test from context 1000

E: Two threads run alternately, each reading and writing value does not affect each other

So it's a good idea to define a global static variable, so the thread is unsafe and dangerous.

3. Some people will mention HttpContext

It is true that HttpContext.Current.Items can achieve this, but httpcontext.current is not ubiquitous, and non-web applications are null

Even Web projects cannot abuse httpcontext.current, which is also null in asynchronous threads, and can be tried.

But HttpContext.Current is still useful, and the appcontext I'm implementing here has a call to HttpContext.Current, and if it's null, another more mysterious thing to call CallContext

Let's take a look at the implementation code:

There are asynchronous operations in the Web program that will switch threads, requiring the thread to copy the online object, using HttpModule (the following code comes from a blog park The great god, I almost did not change)

4. Service (configuration) scope

4.1 See Modeling Code First

Read it a little bit:

A:greet is used to greet, name to who sends a greeting

B:person is obviously representative of a person, which has a Chindren attribute that represents a subordinate sub-object (to simplify the use of the same type)

C:person has a Sayer attribute that is used to greet other "people"

D: From Method Greet (Greet sayer, person person) it can be seen that if the Sayer object is not taken, the greeting fails (hint Sayer is Miss)

E: When great to another object, each sub-object is traversed to "greet" the object individually (the child of this family is really polite, the adults greet him, and every child greets him)

4.2 See test code again

Also read:

A: Defines another sub-object of A,a1,b and a

B: Where only the A object has the Sayer property set

The C:a object great B (where all child objects of the implied a greate to B), and the A1 object greate a separate b

4.3 See run results

Haha, isn't it a little surprised to see the results?

A:A's Hello to B was a good success, but the two sub-objects of a also succeeded to the Hello of B.

B: Even more amazing is that A1 's Hello missing for B is a failure (not inheriting the parent object's properties)

C: Here is a step in the online text, is the scope, only a to B use their own Sayer property, other objects (not necessarily their own sub-objects) can also intercept the value of Sayer, but after the A object is used to recycle, the other people will not use

4.4 Principle Analysis

Here is a using scope, Appcontext.createresource register in the online text or find the object of type greate name A, the candidate value is Sayer, save in Resource. In entity

4.5来 look at the source code of the implementation

Haha, isn't it a little complicated?

A: Implement IDisposable to use using to control the scope

B:dispose also is not simple to remove the scope of the object, if _needdispose is false does not delete the object (not the object created by itself does not have permission to delete)

C: In addition to delete some time also want to restored (_needrestored to True), their scope ends, the backup of the _entity0 back

The D:init method attempts to get the object from the scope and back up to _entity0 if the candidate object is not valid directly using the scope of an existing object, and if valid, overwrite the scope (with a _entity0 backup can be restored back)

E: Not very interesting, just like the definition of variables, small scopes can override the variables of the upper role, leaving the small role, outside the scope of the variable can be used

5, the role of the scope

5.1 I specifically developed this feature to simplify system configuration

5.2 such as log (with exception debug log) Almost every object needs to function

If each object is configured with these common properties, the configuration is too much work and the configuration file is too messy.

If hard-coded to die, wouldn't that be backwards to 800 years ago?

Not all are not worthy, only the special needs of the configuration, if the need to log on the outermost configuration (or just initialize a scope), the child objects inside the call can also share the outer configuration (shared Log service)

Someone might say conflict. What to do, isolate with name

6. Application Context Caching

This cache can only be scoped to the current session (thread or request), so it is inherently thread-safe (so that dictionary is useless concurrentdictionary)

Someone may want to laugh at me, is the cache not all distributed? Is your cache utilization too low?

Yes, you have to say cache utilization is really not and distributed. But think of this more than the session session (do not have to clear the next request reinitialization, do not worry about being invented (modified SessionID)) cache (direct dictionary), naturally also as the session without worrying about user data string

Simple to use, directly new can be used, even if the definition of a global static variable is "thread (session) security", can also be configured in the container to use the ease of

Test Project Download

The component is written so much for the time being. So many days a day to write code for a long time every day, write a lot of sweat, write a number of code, but it is the first time after work debugging, and debugging through a I very much like the on-line text scope component (of course, there is the optimization of the place)

Here's a quick introduction to this framework:

Here is the project solution:

A: The first diagram is the solution, part of the Extended functionality project, which requires a lot of people to participate in the perfect

B: The next four diagrams are the main projects of the framework, most of which have been developed and have not yet been tested, followed by a lot of tests to fix bugs and improve functionality

C: The main framework itself does not seek to solve all of the methods, but rather defines the interfaces of some common functional logic, provides default implementations and partial "design mode" functionality for some interfaces, and extends the implementation of other functions in other projects

D: The main framework does not contain calls to specific data or to which ORM tool and does not contain specific open source external log components and containers.

E: In short, the main framework abstract interface, the implementation of a very common part of the function, as few references

F: Other functions are expected to be developed by the interface of the main frame for easy integration into the main frame, or other modules

The application context scope component of ASP. NET-oriented interface framework