Generics in Serviced Component interfaces.

Here’s a thing that’s bugging me right now. I’m refactoring a client server application to use Enterprise Services. It’s already split into UI, Buslness Logic and Data Access on the client with direct calls to the SQL server stored procedures so we’re just moving some of those layers to the server and turning them into serviced components. Simple and effective….OK so it’s not THAT simple but in broad strokes that’s the strategy.
So I’m looking at the newly formed COM+ API with its interfaces and methods using the Component Services explorer and I notice that lots of the methods are missing. I mean, I know they’re there right, because I can call them and they work, but COM+ is telling me that they don’t exist.
It turns out that the thing all of the “missing” methods have in common is that they have a generic somewhere in the method signature, like 
int foo(Nullable<int> bar);
List<string> foo(string bar);
 So I ask around and I get a number of explanations/guesses, a common one being “you can’t use generics across a COM+ boundary”. But, sure I can, because these methods are working. So what’s the deal here ?
I know that if I have a simple signature like : 
int foo(string bar);
 then COM+ will have no problem with it and I am wondering if this is similar to the issue with the serializer. There are some CLR types (mainly the value types) that COM+ understands and so if a method signature contains only these types the COM+ serializer will be used when the method is called. However, if the method signature contains a type that COM+ does not undertsand and cannot serialize it will defer to the .NET remoting serializer when the method is called. Similarly when I query the interface COM+ simply doesn’t have the language to communicate the method signatures of the methods that contain generics because it’s stuck with IDL so it doesn’t bother trying. But then if I look at method signatures that have DataSets, or strongly typed derivatives thereof, in them they appear just fine so IDL is communicating those just fine.
So maybe I shouldn’t be worrying about this because it works and if it ain’t broke….right ? But now I’m looking at profiling this application and I’m looking at various tools that will give me some metrics on calls to the methods in the COM+ API and I have a sneaking suspicion that the metrics for all my missing methods are going to get lumped together under calls to IRemoteDispatch or some such horror.
Anyway, I banged my head on this for a while and in the end I took a flyer and emailed Juval Lowy. Yes, me. I did that. So over the weekend I exchange a few emails with Juval and you know what ? He didn’t tell me the answer. I think he kind of hinted at it but in the end what he actually did was make me feel a whole lot better about learning not to care. I mean, if you look at this method : 
DataSet GetData(Nullable<int> id);
why would I spend hours agonising over the perfomance issues that might be associated with the difference between Nullable<int> and just int. I’ve already made my bed in performance terms by deciding to pass a DataSet. At the end of the day I have a working application, the client is happy and if performance is adequate why should I care ? The answer is, I don’t know, I just know that I do and I find it hard not to.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: