Lightweight. NET object Lookup service and AOP development Framework Netop.core Source Commentary (3)--class factory/Object lookup service

Tag: Control property Type ISP SDN get document void down

The last section discusses the Netop.core of the application system configuration information processing, for Netop.core the most core service-class factory/Object lookup service of course to use the configuration services, and so on.

For the Net class factory/Object lookup service, the famous spring.net (which corresponds to Java's spring---called lightweight middleware), why do you want to recreate a wheel? If spring is lightweight, then the Netop.core is only

can be micro-level, good enough, learning curve will be greatly reduced, learning to study the code time will also be greatly reduced.
Good enough, why not? Besides, Netop.core's class factory/object lookup service, in addition to instantiating local services, also handles remote service (NET Remoting) and WCF services uniformly, meaning that the reference end

The order is instantiated through Netop.core's class factory/object lookup service, it is not known or known whether the service is local or remote service (NET Remoting) or a WCF service.
The Netop.core class factory/Object lookup service is configured for each app service, starting with its configuration: the configuration file (which can be viewed in the test program's configuration file) is configured at least under the Netop.application node:
<Application.ObjectLocator>
<defaultappobjectlocatorservice>netop.core.locatorservice.defaultappobjectlocatorservice,netop.core</ Defaultappobjectlocatorservice>
<ObjectServiceAgentName>AppObjectService</ObjectServiceAgentName>
<AspectAgentName>AppAspect</AspectAgentName>
</Application.ObjectLocator>
<Application.Agent>
<agent name= "Appobjectservice" type= "Netop.core.configuration.fileagentconfiguration,netop.core" >
<File>Service.xml</File>
</Agent>
<agent name= "Appaspect" type= "Netop.core.configuration.fileagentconfiguration,netop.core" >
<File>Aspect.xml</File>
</Agent>
</Application.Agent>
</Application.ObjectLocator>

<AspectAgentName>AppAspect</AspectAgentName> is configuring an AOP service, and the next section will say that it is not currently expressed.
<ObjectServiceAgentName>AppObjectService</ObjectServiceAgentName> The Appobjectservice name in the application.agent corresponds to the information in the Name= "Appobjectservice" of the node under the agent:

<agent name= "Appobjectservice" type= "Netop.core.configuration.fileagentconfiguration,netop.core" >
<File>Service.xml</File>
</Agent>

View the contents of the AppObjectLocatorConfiguration.cs file, Objectserviceconfigurationmanager class by calling Appobjectlocatorconfigurationmanager.current Get

Application.objectlocator information to obtain the objectserviceagentname corresponding configuration proxy name, and then by invoking the configuration Proxy service to get service.xml content. The contents of the test program Service.xml are as follows:
<Application.ObjectService>
<object name= "A1" type= "Test.core.service1,test.core" >
<property name= "Service2" ref = "A2"/>
</Object>
<object name= "A2" type= "Test.core.service2,test.core" >
</Object>
<object name= "A3" type= "Test.core.service3,test.core" isaspect= "1" >
</Object>
</Application.ObjectService>

With the premise of getting service.xml content, the actual class factory/object lookup service is to implement this interface:
public interface Iobjectlocator:idisposable
{
Object GetObject (string objectName);
void Freeobject (String objectservicename, Object obj);

Type Getobjecttype (string objectName);
BOOL Issingleton (string objectName);
BOOL Isremotingobject (string objectName);
BOOL Iscommunicationobject (string objectName);
}
The classes that implement this interface are as follows

<defaultappobjectlocatorservice>netop.core.locatorservice.defaultappobjectlocatorservice,netop.core</ The defaultappobjectlocatorservice> is configured to

Defaultappobjectlocatorservice This class, defaultappobjectlocatorservice the most important method is GetObject, which is the method of acquiring the object, Another freeobject is the method of releasing the object.
Having done this, unity is provided by the program Appobjectlocatormanager to external program calls.
The following are narrated from the local service, the remote service (NET Remoting) and the WCF service three aspects respectively:

First, local services
The local service also partially implements the value injection (value value injection and reference injection) of the dependency injection (Dependency injection)/control inversion (inversion), in order to micro-quantify no construction injection (theoretically structured note

can also be injected into the same application function by setting value).
The normal local service configuration is:
<object name= "A2" type= "Test.core.service2,test.core" >
</Object>
All configurations have a setting of name type.
The above is configured as: Name of the Test.core.service2,test.core type service called A2, called:
IService2 s2 = Netop.Core.LocatorService.AppObjectLocatorManager.GetObject ("A2") as IService2;
Call when not in use: Netop.Core.LocatorService.AppObjectLocatorManager.FreeObject ("A2", S2);
The configuration can also increase the service if a singleton (Issingleton), such as the value of Issingleton is "true" or "1" or "yes", is a singleton service, otherwise it is not a singleton service. Default is non-singleton service.
<object name= "A2" type= "Test.core.service2,test.core" issingleton= "true" >
</Object>
1. Local Service with value injection
Configured to:
<object name= "A" type= "netop.test.a,netop.test" Issingleton = "true" >
<property name= "Code" value= "2222" ></Property>
</Object>
The attribute code is injected with a value of "2222" when instantiated. Calls and Issingleton are similar to ordinary local services.
2. Local Service with reference injection
Configured to:
<object name= "A1" type= "Test.core.service1,test.core" >
<property name= "Service2" ref = "A2"/>
</Object>
<object name= "A2" type= "Test.core.service2,test.core" >
</Object>
The Service1 property Service2 is referenced by the "A2" service, which is injected when instantiated. Calls and Issingleton are the same as common local services.

Settings for value injection and Issingleton are only available for local services.

Second, remote services (NET Remoting)
NET Remoting is an excellent remote service prior to the advent of WCF services, but after the WCF service comes out, it is obsolete and is retained primarily for compatibility and is not intended to be rewritten as a WCF server for legacy NET Remoting programs

The Lazy people (as the boss is not willing to take the time to spend money to consider the cost).
NET remoting service side of the release and configuration is not mentioned, interested friends can go to see the relevant information. For the reference side (client), the user does not have to make any other configuration, except to configure in the Service.xml file:

<object name= "A1" type= "Test2.service1,test2" location= "Http://127.0.0.1:8989/Test2" isclientactivated= "true" ></Object>
<object name= "A2" type= "Test2.service2,test2" location= "Http://127.0.0.1:8989/Service2.rem" ></Object>
<object name= "A1iis" type= "Test2.service1,test2" location= "Http://127.0.0.1/ROS" isclientactivated= "true" > </Object>
<object name= "A2iis" type= "Test2.service2,test2" location= "Http://127.0.0.1/ROS/Service2.rem" ></object >
That is, remote service to set location, optional settings isclientactivated. Location is server-side (non-IIS publishing also includes ports), isclientactivated= "True" indicates client activation, otherwise the server

Activated.
Call the same as a normal local service.
The remote service is not allowed to set value injection and Issingleton, because the nature of its instantiation is just a proxy object.

Third, WCF services
The use of WCF services is more complex, as illustrated below. For WCF services:

Contract for
Namespace contracts{
[ServiceContract (Name = "Testservice", namespace= "http://www.Netop.com")]
public interface Itestservice
{
[OperationContract]
String MyOperation1 (string myvalue);
}
}
Implemented as:
public class Testservice:itestservice
{
public string MyOperation1 (string myvalue)
{return "Hello:" + myvalue; }
}

And then you have to do this:
1, first to implement a client proxy class that inherits System.servicemodel.clientbase<t>
The client proxy classes that inherit system.servicemodel.clientbase<t> are:

Namespace test{
[System.Diagnostics.DebuggerStepThroughAttribute ()]
[System.CodeDom.Compiler.GeneratedCodeAttribute ("System.ServiceModel", "4.0.0.0")]
public partial class Testserviceclient:system.servicemodel.clientbase<itestservice>, Itestservice
{
Public testserviceclient () {}
Public testserviceclient (String endpointconfigurationname): Base (endpointconfigurationname) {}
Public Testserviceclient (String endpointconfigurationname, String remoteaddress): Base (Endpointconfigurationname, remoteaddress) {}
Public Testserviceclient (String endpointconfigurationname, System.ServiceModel.EndpointAddress remoteaddress): base (Endpointconfigurationname,

remoteaddress) {}
Public Testserviceclient (System.ServiceModel.Channels.Binding Binding, System.ServiceModel.EndpointAddress remoteaddress): Base (binding,

remoteaddress) {}

public string MyOperation1 (string myvalue)
{
Return base. Channel.myoperation1 (myvalue);
}
}
}
2, the server and the client how to configure or how to configure (please refer to the WCF data, not in detail here)
As configured on the client side is:
<system.serviceModel>
<client>
<endpoint address= "Http://127.0.0.1/Test/TestService.svc" binding= "Wshttpbinding"
contract= "Contracts.itestservice" name= "Testservice"/>
</client>
</system.serviceModel>

3, the configuration of the Service.xml is:
<object name= "TestService1" type= "Test.testserviceclient,test" communicationobjectendpointname= "TestService" >
</Object>

The WCF service sets the Communicationobjectendpointname property more than once.
That is, the value of type is the full name of the client proxy object that inherits System.servicemodel.clientbase<t>, and the value of Communicationobjectendpointname is the WCF service name configured by the client.

Call the same as a normal local service.
Contracts.itestservice TestService1 = Netop.Core.LocatorService.AppObjectLocatorManager.GetObject ("TestService1") As Contracts.itestservice;
Do not use when you must remember to call: Netop.Core.LocatorService.AppObjectLocatorManager.FreeObject ("TestService1", TestService1);

WCF services cannot set value injection and Issingleton, because the nature of its instantiation is simply a proxy object.

To summarize: The Defaultappobjectlocatorservice class implements the Iobjectlocator interface, and GetObject implements references to local services, remote services (NET Remoting), and WCF services. The local service also implements a dependency

Injection of the value of the injection, of course, the implementation of the next section of the aop--will talk about the content. Regardless of all of the above implementations, the final call is only GetObject and Freeobject, as follows:

IService2 s2 = Netop.Core.LocatorService.AppObjectLocatorManager.GetObject ("A2") as IService2;
...//other code

Netop.Core.LocatorService.AppObjectLocatorManager.FreeObject ("A2", S2);

It's so simple!

Lightweight. NET Object Lookup Service and AOP development Framework source netop.core3.5:http://download.csdn.net/detail/tom_cat_xie_jxdy/9837303

Lightweight. Net Object Lookup Service and AOP Development Framework test Source: http://download.csdn.Net/detail/tom_cat_xie_jxdy/9837278

netop.core--lightweight. NET Object Lookup service and AOP Development Framework Documentation: HTTP://DOWNLOAD.CSDN.NET/DETAIL/TOM_CAT_XIE_JXDY/9838212

Lightweight. NET object Lookup service and AOP development Framework Netop.core Source Commentary (3)--class factory/Object lookup service