>>It depends on how the COM component is built and accessed - if you're using an MTDLL or out of process server, which can support similutaneous timesliced access to services rather than having to wait on a single method call to complete before servicing the next, there may be advantages to packaging them together.
>>
>>In the case of native VFP classes, if you have a single large VCX containing every concievable instance of all your classes, then any time you build a project that uses any one of them, they're all going to get built into your app, resulting in lots of bloat.
>
>Hi Ed,
>
>Thanks for the info. I was mistakenly thinking about middle tier objects when asked. I've got a pretty good idea now. Just got put it into practice. thanks again.

Think about it logically - the COM component or class library should encompass some coherent level of functionality, that makes sense to bundle together from the standpoint of when it'll get used. It doesn't make sense to have unrelated functionality in a component or a class library, where use of a small part of it requires all of it to be provided for.

An example is a product I've been involved with developing for a number of years, Carrier Manager, which is a shipping and logisitics component. The base engine, which manipulates the common rating engine, manages the component's use of memory, and manipulates the common data objects for the process, common data concepts like a package, a shipment, an origin, a destination, are bundled into a single COM component package with several interfaces, because all of the functionality is required when the common functionality of rating and planning shipments of goods is needed.

OTOH, the components that implement the individual carriers are not all squished together in a single module. You don't have to use FedEx is you use RPS (even though FedEx is the owner of RPS now!) Each carrier component is a separate server, so that the functionality is limited. This helps us at rate change time - if the Post Office changes its rates and services, there's nothing forcing UPS to change at the same time.

It could be argued that each carrier could contain the common functionality for the engine, so that any carrier could 'stand by itself'. This makes it harder to coordinate shared COM behaviors and keep track of exactly which base engine was invoked. Again, we can change the base engine component independent of the carriers (as long as the interfaces remain the same) so we gain flexibility to change the common environment this way.