Using an Interop layer with BizTalk

This is my second project in which I used an Interop layer for calling custom code in BizTalk and it still feels (and smells) good.


The Interop layer is an assembly that isolates the BizTalk specifics from the rest of your code base (I’ve not needed more than a single assembly but I can imagine you might want to split things up in multiple assemblies with bigger and more diverse projects). The BizTalk specific types are only used in this assembly and requirements like [Serializable] are also implemented here (if not supported by underlying code base). Note that I do not use the Interop layer for Pipeline Components: each pipeline component is an ‘interop layer’ on its own – so I do take care not to leak any BizTalk specifics into the general code base.


Some examples of the types of classes I found myself writing in the Interop assembly are:




  • Message Factory classes
    Easily construct new message instances using BizTalk (XLANG) specific types.


  • Content Enrichment classes
    Classes that fetch additional information and return it as Xml (string) for use in maps. See also my post on How to Enrich a Message.


  • Configuration classes
    A serializable class that contains configuration settings in an orchestration; when you want to keep the settings an orchestration works with during its lifetime constant.


  • Collection / Iterator classes
    Classes that represent a collection of (domain) information and can be used inside a Loop shape (MoveNext/Current).


  • Xml Aggregator class
    A serializable class that knows how to generically aggregate multiple Xml documents into a single Xml document (of the same schema).

The fact that the Interop layer shields the rest of you custom code base from BizTalk specifics makes your (non interop/other) code Unit Testable without having to resort to ‘creatative’ injection techniques ;-).


I hope it works just as well for you as it has for me.

Why do we not design a class like this?

I started learning WPF some time ago and the first thing that struck me was the sheer number of properties available on these classes. It turns out that those properties are mainly there to make support for Xaml (declaritive programming) easier/better. But even before WPF, WinForms too had its share of properties on its classes.

 

So I wondered why would we want to have so many Font-properties on a class in WPF; at least in WinForms its on a Font object and the Form/Control only has a Font property (the answer has probably to do with Xaml -again).

 

To be more generic: why do we not (in general) design our class properties to be grouped in functional related groups and make these groups class properties themselves?

 

So instead of (public fields used for clarity):

 

public class MyClass
{
public int MinWidth;
public int MinHeight;
public int MaxWidth;
public int MaxHeight;

// …more properties
}

 

Why don’t we make code like this:

 

public class MyClass
{
public Dimension Dimension = new Dimension();

public struct Dimension
{
public int MinWidth;
public int MinHeight;
public int MaxWidth;
public int MaxHeight;
}

// …more property groups
}

 

For classes with a lot of properties this would make things a little more navigatable for the user of that class (i would think). When there are several pages of intellisense worth of properties (in the first example) you would be able to reduce that to only a handfull of groups. Note that I propose a property group as a struct: its merely a container for properties and has no functionality of its own.

 

One of the downsides of this approach could be that accessing the main class from a property implementation in a property group requires passing┬áthat reference to all property groups. On the otherhand: most property implementations are pretty simple anyway…

 

Thoughts?