{"id":1254,"date":"2021-02-15T00:05:15","date_gmt":"2021-02-15T05:05:15","guid":{"rendered":"https:\/\/badecho.com\/?p=1254"},"modified":"2022-02-22T01:07:39","modified_gmt":"2022-02-22T06:07:39","slug":"segmenting-contracts-dispatchproxy","status":"publish","type":"post","link":"https:\/\/badecho.com\/index.php\/2021\/02\/15\/segmenting-contracts-dispatchproxy\/","title":{"rendered":"Segmenting Contracts With DispatchProxy in .NET 5.0"},"content":{"rendered":"\n
\".NET<\/figure><\/div>\n\n\n\n

On the Nature of Segmenting Contracts<\/h2>\n\n\n\n

Not long after wrapping up the publishing of some of the foundational aspects of my Extensibility framework to my Bad Echo Technologies repo<\/a>, I needed to start working on another side of the framework: support for my IHostAdapter<\/code> interface. Implementations of this interface are responsible for establishing connections between a host and several routable plugin adapters that segment a common contract.<\/p>\n\n\n\n

What does it mean to segment a contract? Let’s, for instance, say we have an interface named IContract<\/code>, with the methods IContract.MethodOne<\/code> and IContract.MethodTwo<\/code>. Then, let’s also assume we have two plugin assemblies, PluginA.dll and PluginB.dll, each with their own implementation of IContract<\/code>. If we create a proxy that will route IContract<\/code> method calls to PluginA.dll and PluginB.dll based on the particular method being called, then we have essentially segmented the IContract<\/code> contract.<\/p>\n\n\n\n

Segmenting IContract: An Illustration<\/h3>\n\n\n\n
\"Shows
Here we see IContract segmented: different method calls being routed to different plugins.<\/figcaption><\/figure><\/div>\n\n\n\n

The inspiration behind this concept came from one of the more significant kinds of creative drivers: attempting to sell a business proposition. In my first job out of college, I was working with a client\/server software solution that had a lot of market potential, but was plagued with horrible technological burdens. It was one of those pieces of software that indeed needed a complete rewrite, but of course I needed to convince the business owners to allow me to embark on such an endeavor. <\/p>\n\n\n\n

I was able to convince the owner to allow me to rewrite it by telling him I would develop a shiny new frontend client first, and only after that would I spend time redeveloping the backend. This would allow the company to begin to market and sell the shiny new frontend after a much shorter period of time than what would be required if we went about it the traditional way (making the backend first and then the frontend). So, essentially, a quicker capturing of profits from the rewrite effort.<\/p>\n\n\n\n

Because the new frontend would be operating against a brand new system service contract, I needed a way to reroute calls made to this new contract to the old backend. As the new backend was being developed, I would slowly shift responsibility for what ultimately processed service calls to it. In order to achieve all of this, I came up with this segmented contract approach.<\/p>\n\n\n\n

On the Nature of Generating Proxy Objects<\/h2>\n\n\n\n

This article isn’t about the complete implementation of a contract segmentation solution, but rather how I went about generating the proxy objects that the solution requires while working on reorienting my treasure trove of code to run on top of .NET 5.0.<\/p>\n\n\n\n

Typically when we’re talking about proxy objects, we’re talking about them in the context of mocks, stubs, and\/or fakes. Fake objects adhering to some kind of interface that we configure at runtime to behave in a manner that aids in the process of testing a particular piece of code. What we’re doing here is very much a non-testing concern, but may benefit from the same bits of technology that testing-oriented frameworks that provide such objects use.<\/p>\n\n\n\n

That’s how I approached the problem originally, and it led me to end up using Castle.Core<\/a> for my original solution. This is a very well known third-party library, and it makes available a runtime proxy generator known as Castle DynamicProxy<\/strong>. Using this library I satisfied the proxy-related concerns of contract segmentation by using Castle’s ProxyGenerator<\/code> class and a custom IInterceptor<\/code> implementation in order to reroute an interface’s method calls.<\/p>\n\n\n\n

It’s my goal to avoid excessive reliance on third-party libraries with the Bad Echo core frameworks library, the general-purpose library I’m building, but I decided to just swallow my pride a bit and add the Castle.Core NuGet package to the project. It was then that I saw that Castle.Core targets an older version of .NET Standard, and the amount of dependencies it wanted to bring along with it disturbed me slightly, making me uneasy enough to stop what I was doing.<\/p>\n\n\n\n

Another stumbling stone encountered. I started to think (and hope) about whether or not something was built into Microsoft’s latest .NET installment, namely .NET 5.0, that could help me generate proxy objects. And, to my surprise, there was!<\/p>\n\n\n\n

Making a Routable Proxy with DispatchProxy<\/h2>\n\n\n\n

The DispatchProxy<\/code><\/a> class is (from what I can tell) new to .NET Core and is a very nice way of going about generating proxy objects if we’re building on top of .NET 5.0. Looking at its source code, it is evident that it makes use of Reflection.Emit<\/code>, just like Castle.Core does, to create a dynamic proxy at runtime. <\/p>\n\n\n\n

If a built-in solution satisfies requirements just as well as a third-party solution, I will 99% of the time gravitate towards adopting the built-in approach. That being said, I would very much be interested in measuring and analyzing performance differences between DispatchProxy<\/code> and Castle.Core’s own proxy generating classes. That can be done some other day, however. I will give DispatchProxy<\/code> the benefit of the doubt until then.<\/p>\n\n\n\n

It wasn’t long until some annoyances popped out at me when attempting to use DispatchProxy<\/code> to create my routable proxy:<\/p>\n\n\n\n