Designing for Scalability with Microsoft Windows DNA (DV-MPS Designing)

[Previous] [Next]

MTS offers two kinds of packages, just as COM+ Component Services offers two kinds of COM+ applications:

In this book's sample application, only one of the components we've mentioned so far should be installed in a library package or an application. It's the RaceADOSrvcs class, which contains the GetNewNumber method to supply the component's clients with new ID numbers for specified database tables. We've included this class in the RaceDataAccess project, but in a real production environment this wouldn't be the best place for it. It's much better to put it in its own DLL project instead and then install that DLL in a library MTS package or COM+ application.

In our examples, every data access object performs basic ADO operations. You could segregate these basic operations and put them in the RaceADOSrvcs class, and so have them run in a library package or application as well. All data access objects could reuse the code for these operations, and because it's a library component all calls to the component would be in-process and therefore fast.

Library packages and applications are meant for components that need to be called by clients living in different packages or applications. There's no way in COM+ or MTS to install the same component in more than one application or package—both COM+ and MTS forbid that. You can install such a component in a standard application or package, but if you do, every time another object calls it from another COM+ application, the call is made cross-process, which degrades the performance of the component. The best place for these components is in a library application.

Another type of component that might like being in a library application is the kind of error handling component we talked about loosely at the end of Chapter 22, "What About the Business Rules?"

Категории