Lightweight. NET Object Search Service and AOP development framework Netop. Core source code explanation (3) -- class factory/Object Search Service, aopnetop. core
I talked about Netop in the previous section. core processing of application system configuration information, for Netop. core services-class factory/Object Search Services must use the configuration service.
For the NET factory/Object Search Service, Spring. Net (Spring corresponding to Java-known as lightweight middleware) is well-known. Why do we need to create another wheel? If Spring is lightweight, Netop. Core can only be trace-level. If it is enough, the learning curve will be greatly reduced, and the time to study the code will also be greatly reduced.
Just enough. Why not? Besides, Netop. in addition to instantiating the local service, the Core class factory/Object Search Service also uniformly processes the remote service (NET Remoting) and the WCF Service, that is, the reference end program passes the Netop. when the Core class factory/Object Search Service is instantiated, you do not have to know whether the service is local or remote (NET Remoting) or WCF Service.
Netop. the Core class factory/Object Search Service must be configured for each application service. Let's start with its configuration: In the configuration file (you can view the configuration file of the Test Program) Netop. at least configuration is required under the 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 used to configure the AOP service. It is not described in the next section.
The AppObjectService name in <ObjectServiceAgentName> AppObjectService </ObjectServiceAgentName> corresponds to the Agent name = "AppObjectService" of the node under Application. Agent:
<Agent name = "AppObjectService" type = "Netop. Core. Configuration. FileAgentConfiguration, Netop. Core">
<File> Service. xml </File>
</Agent>
View AppObjectLocatorConfiguration. cs file content. The ObjectServiceConfigurationManager class calls AppObjectLocatorConfigurationManager. current to obtain the Application. objectLocator information to obtain the configuration proxy name corresponding to ObjectServiceAgentName, and then obtain the Service by calling the configuration proxy Service. xml content. For example, the content of Service. xml is 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 the content of Service. xml, the actual class factory/Object Search 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 class that implements this interface is like <DefaultAppObjectLocatorService> Netop. core. locatorService. defaultAppObjectLocatorService, Netop. core </DefaultAppObjectLocatorService> is configured with the DefaultAppObjectLocatorService class. The most important method of DefaultAppObjectLocatorService is GetObject, which is the method for obtaining objects, and another FreeObject is to release objects.
After completing these steps, AppObjectLocatorManager provides external program calls.
The following is an explanation of the local service, remote service (NET Remoting), and WCF Service:
1. Local Services
The local service also partially implements Dependency Injection/Inversion of Control (Inversion of Control) value Injection (value Injection and reference Injection ), in order to reduce the number of constructor injections, the same application function can be used to create constructor injection theoretically ).
The common local service configuration is as follows:
<Object name = "A2" type = "Test. Core. Service2, Test. Core">
</Object>
All configurations have the name and type settings.
The above configuration is: type service named Test. Core. Service2 and Test. Core of 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 also adds whether the service is Singleton. If the value of isSingleton is "true" or "1" or "yes", it is a singleton service, otherwise, it is not a singleton service. It is a non-singleton service by default.
<Object name = "A2" type = "Test. Core. Service2, Test. Core" isSingleton = "true">
</Object>
1. Local Service with value Injection
Configuration:
<Object name = "A" type = "Netop. Test. A, Netop. Test" isSingleton = "true">
<Property name = "Code" value = "2222"> </Property>
</Object>
The Property Code will be injected with a "2222" value during instantiation. The call and isSingleton are similar to common local services.
2. Local services with reference Injection
Configuration:
<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 attribute Service2 refers to the "A2" service. It will be injected during instantiation, and isSingleton will be the same as the common local service.
Only the local service can set the value injection and isSingleton.
Ii. NET Remoting)
NET Remoting is an excellent remote service before the emergence of the WCF Service, but it is an elimination technology after the emergence of the WCF Service. Currently, it is mainly for compatibility, and for those lazy people who don't want to rewrite the old NET Remoting program to the WCF Service (as the boss considers the cost rather than spending time and money ).
NET Remoting Server Release and configuration are not mentioned, interested friends can go to view the relevant information. For the reference end (client), you do not need to configure anything else except 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, to set the location for the remote service, you can set isClientActivated. Location is the server end location (non-IIS publishing and port inclusion). isClientActivated = "true" indicates that the client is activated; otherwise, the server is activated.
The call is the same as that of a common local service.
Remote services cannot set value injection and isSingleton, because the essence of Instantiation is just a proxy object.
Iii. WCF Service
The use of the WCF Service is more complex. The following example shows how to use the service. For WCF services:
Contract:
Namespace Contracts {
[ServiceContract (Name = "TestService", Namespace = "http://www.Netop.com")]
Public interface ITestService
{
[OperationContract]
String MyOperation1 (string myValue );
}
}
Implementation:
Public class TestService: ITestService
{
Public string MyOperation1 (string myValue)
{Return "Hello:" + myValue ;}
}
Then, you need:
1. First, implement a client proxy class that inherits System. ServiceModel. ClientBase <T>.
The client proxy class that inherits System. ServiceModel. ClientBase <T> is:
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. How to configure the server and client? (refer to the relevant WCF documents for details here)
For example, the configuration on the client is as follows:
<System. serviceModel>
<Client>
<Endpoint address = "http: // 127.0.0.1/Test/TestService. svc" binding = "wsHttpBinding"
Contract = "Contracts. ITestService" name = "TestService"/>
</Client>
</System. serviceModel>
3. Configure Service. xml as follows:
<Object name = "TestService1" type = "Test. TestServiceClient, Test" communicationObjectEndpointName = "TestService">
</Object>
For the WCF Service, you must set the communicationObjectEndpointName attribute. That is, the value of type is the full name of the client proxy object inherited from System. ServiceModel. ClientBase <T>, and the value of communicationObjectEndpointName is the WCF Service name configured by the client.
The call is the same as that of a common local service.
Contracts. ITestService testService1 = Netop. Core. LocatorService. AppObjectLocatorManager. GetObject ("TestService1") as Contracts. ITestService;
Remember to call Netop. Core. LocatorService. AppObjectLocatorManager. FreeObject ("TestService1", testService1) when not in use );
The WCF Service cannot set value injection and isSingleton, because the essence of Instantiation is only a proxy object.
To sum up, the DefaultAppObjectLocatorService class implements the IObjectLocator interface. GetObject implements the reference of local services, remote services (NET Remoting), and WCF services. The local service also implements set-value injection in dependency injection, and of course also implements AOP-what will be discussed in the next section. Regardless of the above implementation, the final call is only GetObject and FreeObject, as shown below:
IService2 s2 = Netop. Core. LocatorService. AppObjectLocatorManager. GetObject ("A2") as IService2;
... // Other code
Netop. Core. LocatorService. AppObjectLocatorManager. FreeObject ("A2", s2 );
That's easy!
Lightweight. NET Object Search Service and AOP development framework source code Netop. Core3.5: http://download.csdn.NET/detail/tom_cat_xie_jxdy/9837303
Lightweight. NET Object Search Service and AOP development framework test source code: 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