Using a COM interface for data access in CSLA

Andrew Smith posted on Tuesday, January 11, 2011

Hi,

We've been using CSLA for a couple of months, but I've run into a bit of a problem on our latest project.

Our CSLA objects need to interface with an accounting system which provides a COM interface.

Usually we would create a connection to the accounting system and use that connection for the life of the application, since opening that connection can be an expensive operation.

Since opening the connection within each CSLA object would really hurt the performance of the application, I thought I could open the connection and then pass it into each CSLA object for use with the DataPortal calls. That created a problem since there's an issue with serializing COM objects.

I was thinking about trying to store the connection object within the authorization object, so that each business object would have access to the connection, but I suspect I'll run into the same problem with serialization.

The data portal is running locally.

Any advice?

Thanks,

Andrew

RockfordLhotka replied on Tuesday, January 11, 2011

You should separate your concerns.

1. You have business objects that need data.
2. You have a data access layer that interacts with the data storage mechanism.
3. You have a data storage mechanism that uses a COM API (I assume actually DCOM given the perf issue).
4. Your COM API doesn't currently have any connection pooling or reuse mechanism like you'd find with SQL Server.

Solving the lack of connection pooling isn't an issue to be addressed by the business objects, and probably not even the data access layer. It is something that would ideally be solved at the data storage API level.

Assuming that's the correct train of thought, the question then becomes how to construct a connection pool for the COM connection - basically how do you wrap the RCW with a singleton that can survive the normally stateless nature of the server-side data portal.

If your app is a smart client app, where each client directly makes the COM calls you can put the RCW into Csla.ApplicationContext.LocalContext and reuse it from there. You can look at Csla.Data.ConnectionManager for some ideas on how you might abstract this idea in an elegant manner.

If your app is calling an app server, so it is actual server-side code that is making the COM call, that's harder, because you need some way to share the RCW across multiple client calls, and you probably need to ensure only one client can use it at a time to avoid threading issues. Remember that the app server is multi-threaded, but most COM components aren't thread-safe. In this scenario you probably need to write a real connection pooling mechanism that can safely "issue" an RCW to a client from the pool, ensuring that no other client is using it at the same time. Basically this would work exactly like the connection pooling provided by System.Data.SqlClient for example.

Andrew Smith replied on Wednesday, January 12, 2011

Thanks for the help Rocky, it's very much appreiciated.