Justin does a pretty good job of wondering about the use of ServicedComponents in .NET. I'd like to make a couple on comments on it, though:
I fully agree with Justin that using COM+ (and thus, ServicedComponent) in .NET has more or less fairly limited advantages, in particular, declarative transactions. Quite frankly, I don't care much for the role-based security settings in COM+, as I always found it a little bit restrictive, so I prefer quite a bit more the .NET version of it.
I think that blindly going to ServicedComponent is the wrong way to go. I'd argue that most people used COM+ for the wrong reasons. I've seen too many times VB developers putting all their components in COM+ just because they wanted to access them remotely (poor's man remoting, if you ask me), but never actually using any of the actual COM+ services. A complete waste. So going to COM+ is way overkill for most simple projects. Let's face it: your typical intranet application really doesn't need COM+.
However, I still think COM+ has lots to offer to complex enterprise-level applications, but even so, one should think very carefully about going that way. My main concern is that correctly introducing COM+ into an application (and particularly a .NET application), implies some heavy architectural decisions and changes. You should be fully prepared to deal with the consecuences.
I must admit, though, that, right now, we're faced with this very topic on our current project, and it hasn't been an easy one. I currently think we'll be needing COM+ soon enough, but we have managed to build a lot of functionality without actually using it, which is pretty cool. In particular, it seems we'll really need to get in shape with distributed transactions, and if you're using SQL Server and the SqlClient provider, there's just not much other way to go right now.
My current thinking on all of this is:
- Avoid COM+ unless you actually need its services. If you actually need them, make sure you use them right (yes, reading "Transactional COM+" is actually required; go get it).
- If you must use COM+ in .NET applications, try to stick with library applications if you can. There are some pretty cool benefits (including performance) to sticking with the in-proc scenario.
- Be very aware of the life-cycle implications of mixing managed, ServicedComponent-derived classes with COM+ services.
If anyone has any other advices, love to hear them :)
