Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

A Design Pattern for Creating Reusable COM+ components using Visual Basic and XML

Over the last year or two, quite a few articles and books have been written on COM+, transaction management, and programming stateful & stateless components, explaining in detail what COM+ does and how it does it. When tasked with creating a model for developing lightweight, reusable components, you can found a lot of What-not-How type of articles on COM+, but not a lot of practical How-To type of articles. The author started working through a lot of information on COM+, combined this information with how I wanted a reusable component to behave, and came up with a real easy model for creating reusable COM+ business objects.


advertisement


Download the source code for this article



Over the last year or two, quite a few articles and books have been written on COM+, transaction management and programming stateful & stateless components, explaining to you in detail what COM+ does and how it does it.  When I was tasked with creating a model for developing lightweight, reusable components, I found a lot of What-not-How type of articles on COM+, but not a lot of practical How-To type of articles.  I started working through a lot of information on COM+, combined this information with how I wanted a reusable component to behave, and came up with a real easy model for creating reusable COM+ business objects.

Architecture and Naming Conventions

Lets start off by examining the architecture and naming conventions my components had to fit into.  The following naming conventions have been used for numerous projects in the company and proved to be very useful. 

A component consists of the Business Object (BO) layer on the COM+ machine, and a Client Object (CO) layer that runs on the client machine.  The CO functions as an intermediary between the application and the BO layer.  A component on the CO layer does the following:

  • It gathers configuration information in Plug & Play style (more about this in another article)
  • It functions as a wrapper around business logic in the BO component
  • If provides a stateful COM component to the application, shielding the application from any interaction with BO components

I use the following naming conventions to easily distinguish between classes on different levels.

  • On CO level
    • Project name gets the suffix CO
  • On BO level
    • Project name gets suffix BO
    • Class name gets suffix SVR (Server)
  • Classes get the prefix cls
  • Collection classes gets the prefix col

Figure 1 shows this architecture and naming conventions applied for our sample project, Client.  

Figure 1: Architecture and naming conventions applied to Client project

As with most component-reuse scenarios, the aim is to develop lightweight reusable objects, with some or no business logic. The next step is to create more complex reusable objects by combining the lightweight objects together with real-world business logic. 

At SDT we have a reuse level grading system that we use to indicate the level of reuse you can expect from a specific component.  These levels range from mere concept reuse (level 1) to binary reuse on level 5, with the ultimate being level 6, which is basically level 5 reuse plus a reusable user interface.  Take note that their is an inevitable tradeoff between ultimate reusability and performance.  In this article the focus is on reuse and maintainability rather than on outright performance. In real life, performance is always important, but if your project starts running to 3 to 4 million lines of code, maintainability also becomes a major factor.

The requirements set by SDT for reusable components COM+ are:

  • The component must be on reuse level 5, that is it must be reusable in binary form (a DLL)
  • The component must adhere to above mentioned naming conventions
  • The component must be available for reuse on both the BO and CO level
  • The component must gather any configuration information in Plug & Play style
  • The application must be totally isolated from any internal configuration information about the component it is using.
  • Object state must be maintained on the client machine.
  • Object state must be communicated to and from the BO object for every method to be executed from CO level
  • Changed object state should only be returned to the CO level if the method executed successfully.  If the method should fail, the original object state has to be returned to the CO level.

Sample Projects

I have two projects I will be using as examples.  In order to make the code listings small and easy to read, I kept the properties of the objects to a minimum and removed all error handling code and comments. It adds up to a substantial amount of code, so throughout the article I only show bits and pieces of the code, however all the code for the article is available for download.

Project 1: Client

This component maintains basic client information. The component consists of the following Visual Basic projects and classes:

  • Project: ClientCO
    • clsSystem: The system class is tasked with obtaining configuration information in Plug and Play style for the Client project, such as database connection information (I prefer to keep connection information on CO level and pass it to the BO object with every method call,  as this allows multiple CO objects to use one COM+ machine to work on more than one database)
    • clsClient
  • Project: ClientBO
    • clsClientSVR (MTSTransactionMode = 2: Requires Transaction)

The client table has the following fields:

Figure 2: Client Table

Project 2: Contract

This component maintains basic information regarding insurance contracts.  It also maintains the link between a contract and all the clients associated with that contract.  It will reuse our client component for this task.  The component consists of the following Visual Basic projects and classes:

  • Project: ContractCO
    • clsSystem: The system class is tasked with obtaining configuration information for the Contract project, such as database connection information
    • clsContract
    • clsContractClient
    • colContractClients
  • ContractBO
    • clsContractSVR (MTSTransactionMode = 2: Requires Transaction)
    • clsContractClientSVR (MTSTransactionMode = 2: Requires Transaction)
    • colContractClientsSVR (MTSTransactionMode = 3: Uses Transaction)

 

Figure 3: Contract Tables

Note that on the BO projects, you need to set the following properties: Unattended Execution must be on, Retained in Memory must be on and Binary Compatibility must be set.

 



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date