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
 

'Making Reuse Fun' instead of 'Making Fun of Reuse'

OK, so the COM team enabled us to develop great binary reusable components in DLLs and OCXs. Using all this functionality you develop this amazing component and now you're waiting for the developers to snap it up and start raving. You discover, however, that having a component that can be reused does not guarantee that it will in fact be reused. Amazing capabilities are overshadowed by ease of use and other trivial issues.


advertisement


evelopers using binary reusable components essentially becomes users, and immediately they treat these "black boxes" the same way users treat other programs.  Amazing capabilities are overshadowed by ease of use and other trivial issues.  While I have not discovered the total recipe for "making reuse fun" yet, guys reusing my components agree that the current level of "ease of reuse" certainly provides some happy faces.

Background Information
This article really is part two of my previous article. In fact, the previous article is not complete without this one, but due to the size of the first article, it was decided not to include this information.  This has two implications on this article.  Firstly, I would advise anyone not familiar with the content of the previous article to follow the above link and read the first article prior to reading this one.  Secondly, I am going to use the same samples as in the previous article, plus I am going to repeat some of the information as we will be looking at some of these things in more detail.  So, let's start off by revisit the naming conventions and samples used. 

Naming Conventions and Architecture
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 a smart proxy between the application and the BO layer.  A component on the CO layer does the following:

  • It gathers configuration information in Plug & Play style (the focus of this 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

Sample Projects
While the two sample projects are the same as in the previous article, the code for the samples are not the same.  In the previous code samples, I removed the functionality and complexity associated with the System class (the class discussed in this article), while it is obviously added to the samples for this article.

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

  • Project: ClientCO
    • clsSystem: 
    • clsClient
  • Project: ClientBO
    • clsClientSVR 
    • clsSystemSVR

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
    • clsContract
    • clsContractClient
    • colContractClients
  • ContractBO
    • clsContractSVR 
    • clsContractClientSVR 
    • colContractClientsSVR 
    • clsSystemSVR

 

Figure 3: Contract Tables





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