« März 2007 | Main | Mai 2007 »
27.04.07
WCF Dynamic Proxy
I’m a big fan of WCF XML Messaging, i.e. making use of the Message object and accessing the SOAP envelope directly. In my opinion this approach supports the loosely coupled nature of services best.
Although Untyped Services have no need for generated service proxies and they don’t rely on XML serialization, you have to provide the service contract (.NET interface). You might generate the interface from the published WSDL or write the code by hand. Either way the development of a service contract on the client side is annoying.
The WCF team at NetFx3 has published a WCF Dynamic Proxy, which relies on the WSDL URL in order to create a proxy for communication with a service:
1. Create the ProxyFactory specifying the WSDL URI of the service.
DynamicProxyFactory factory = new DynamicProxyFactory(“http://localhost:8080/WcfSamples/DynamicProxy?wsdl”);
2. Browse the endpoints, metadata, contracts etc.
factory.Endpoints
factory.Metadata
factory.Contracts
factory.Bindings3. Create DynamicProxy to an endpoint by specifying either the endpoint or
contract name.
DynamicProxy proxy = factory.CreateProxy(“ISimpleCalculator”);OR
DynamicProxy proxy = factory.CreateProxy(endpoint);
4. Invoke operations on the DynamicProxy
dobule result = (dobule)proxy.CallMethod(“Add”, 1d ,2d);5. Close the DynamicProxy
proxy.Close();
This is a great way of (really) decoupling your client (consumer) from the service (provider)!
Posted by Hartmut Wilms at 10:50 | Comments (1) | TrackBack
11.04.07
Partial Methods: the Missing Pieces of Code Generation
Partial Classes, a C# 2.0 language feature, are mainly used within code generation. What’s missing today is a means of customizing generated methods. Let’s say your code generator generates a method, which does “something”:
private void MyGeneratedMethod() {
...
// Do Something...
}
If someone wants to add any kind of pre- or post-processing surrounding this “something”, he’s out of luck. Traditionally this problem is solved by introducing protected areas into the generated code. These areas contain code, manually added by the developer, which is “protected” from being eliminated by subsequent code generations. The code generator has to identify these areas and act accordingly. The “protected areas” approach isn’t fool-proof, because protected areas can easily be removed without notification. Partial Methods to the rescue:
// In MyGeneratedClass.generated.cs public partial class MyGeneratedClass {
private void MyGeneratedMethod() {
MyGeneratedMethodPreprocessing();
// Do SomethingMyGeneratedMethodPostprocessing();
}
partial void MyGeneratedMethodPreprocessing();
partial void MyGeneratedMethodPostprocessing();
}
// In MyGeneratedClass.cs public partial class MyGeneratedClass {
partial void MyGeneratedMethodPreprocessing() {
// Do some preprocessing}
partial void MyGeneratedMethodPostprocessing() {
// Do some postprocessing}
}
Partial Methods separate method definition and implementation. A defined method does not have to be implemented, i.e. if a partial method definition isn’t implemented, all calling code is removed by the compiler.
Galin Iliev summarizes the restrictions on partial methods in his blog entry:
-
Partial method declarations must begin with the contextual keyword partial and the method must return void.
-
Partial methods can have ref but not out parameters.
-
Partial methods are implicitly private, and therefore they cannot be virtual.
-
Partial methods cannot be extern, because the presence of the body determines whether they are defining or implementing.
-
Partial methods can have static and unsafe modifiers.
-
Partial methods can be generic. Constraints are placed on the defining partial method declaration, and may optionally be repeated on the implementing one. Parameter and type parameter names do not have to be the same in the implementing declaration as in the defining one.
-
You can not make a delegate to a partial method.
Posted by Hartmut Wilms at 17:32