Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 267
  • Last Modified:

how to use COM tech to seperate program in different blocks

Hi Experts,

How to use COM tech to seperate program in different blocks.
And each one without affect the others.

Thanks and Regards,

Turbot
0
turbot_yu
Asked:
turbot_yu
  • 2
3 Solutions
 
rcarlanCommented:

You don't need to resort to COM for this.

First of all, are you talking about logical "blocks" or physical ones? Although there is a parallel between logical and physical design, they are different.

In terms of logical design, you need to think about services: e.g. data persistence, business logic, user interface, etc. Having identified the logical components and how they interrelate, you need to design communication interfaces between them. In this context, an interface is any communication protocol – although, more often than not, it will be represented by a collection of methods or functions and associated parameters. Each method/function should perform a single action or retrieve a single piece of information (can be many properties/attributes, but they need to be logically related).

This is going to be an iterative process. You should continue refining your model until the functionality of each logical component is clearly defined. At this stage it is not very important how you will implement each logical component (don't think about programming language constructs, and don't get hung up on technologies; stay within the business domain). You should however consider the relative position of each of these services in the overall design. You should also identify performance requirements or considerations for the logical components and their communication interfaces. For example, if your business requirements specify that the data should be stored in a database and that there may be multiple users connecting to the system simultaneously, you will probably decide that the data persistence service should be placed in a "shared" location (in terms of physical design – on a server machine, possibly implemented as a service).


Generally speaking, if you get the logical model right, the physical design flows naturally from it. You should find it easy to decide where to place each logical component - on what machine (if you have a distributed system) and in what physical module.

When you get to this stage, you will start thinking about the technologies you can use to implement each module. It is now that you may consider the benefits and downsides of COM for implementing one or more of your system’s logical components. However, COM will not necessarily be *the* answer. It comes with certain performance costs and it can impede on the development process.

If you do not plan on interfacing with other systems – i.e. for communication between your system’s components – you can use other means of insulating client components from the implementation details of the services they use. For example, seeing how you posted this question in the C++ channel, you can go a long way towards a componentised architecture without the complexity of COM by simply emulating some of its ideas. You can define interfaces for each component as abstract classes containing no data and only pure virtual methods. You can even use the keyword “interface” for them (if your environment doesn’t define the interface keyword, you can do it yourself like this: “#define interface struct”). For example, you may have something like this:

interface IDatasource
{
      virtual bool ConnectTo(const std::string& sDatasourceSpecification) = 0;
      virtual bool IsConnected() const = 0;
      virtual bool CloseConnection() = 0;
      // other data access service

      virtual ~IDatasource() {}
};

Then, in a module somewhere, there would be one or more classes that inherit from IDatasource (i.e. implement the interface). For example, you may have the real/production implementation connecting to a database server, but also a test implementation using a flat file on the local system:

class CDBDatasource : public IDatasource
{
      // IDatasource implementation
      public:
            virtual bool ConnectTo(const std::string& sDatasourceSpecification);
            virtual bool IsConnected() const;
            virtual bool CloseConnection();
            // other data access service

};

class CFileDatasource : public IDatasource
{
      // IDatasource implementation
      public:
            virtual bool ConnectTo(const std::string& sDatasourceSpecification);
            virtual bool IsConnected() const;
            virtual bool CloseConnection();
            // other data access service

};

Each of these would implement the methods differently, but these implementation details would not impact on the client modules. Given an IDatasource pointer, the client would happily use the service regardless of how it’s implemented:

interface IDatasourceClient
{
      virtual void SetDatasource(IDatasource* poDatasource) = 0;
      // other methods for data source clients

      virtual ~ IDatasourceClient() {}
};

There may be many real/production data source clients deriving from IDatasourceClient. Given an IDatasource, they should happily operate with it.


Anyway, I’m sure you get the picture. All logical components in your system should communicate only through such interfaces. This hides implementation details and goes a long way towards decoupling your components.

COM, by virtue of its design, forces this approach upon you. But you don’t have to use COM for this alone. It’s a matter of discipline and design.

Of course, COM brings a bag of other goodies, but they don’t come for free. In particular, because of its strive for independence from any particular programming language, it’s more difficult to exchange custom data types. Also, debugging is more difficult, especially when working with out-of-process COM servers (but I guess this is true whenever your system involves multiple executables, regardless of whether or not they are COM servers). Another pain in the behind can be the security layer, especially when you use DCOM (i.e. distributed COM). Error handling and reporting is also a bit cumbersome in COM – there’s no throwing of exception across COM calls. Also, during development, your interface definitions are likely to be fairly fluid. Whenever you change an interface (even if it’s a ‘private’ one) it can cause a lot of frustration. You either have to employ the rather restrictive versioning system required/recommended by COM, or you may have to forcefully unregister and re-register your COM servers. In a large team, this alone may be enough to cause a mutiny.


I hope you don’t think I’m trying to put you off going down the COM lane. We certainly use COM and DCOM extensively in our company, but we also employ other techniques (like the one described above) when we do not really need any COM-specific functionality or cannot afford the costs associated with it. It’s a matter of using the right tool for the job.


Good luck.

Radu
0
 
grg99Commented:
You might look over the alternatives to COM.  It's not a particularly well thought out concept.  There's even an MSDN article that pokes ironic fun at it.  And Microsoft, its main proponent, has effectively given up on it.    Now we'll never know what that NULL parameter to CoInitialize was going to become.

0
 
rcarlanCommented:
I wouldn't put COM down. If you're familiar with the .NET framework you'll realise it's built right on top of COM.

Everything's there; all the standard COM interfaces, obviously the concepts, everything. Why do you think the COM interop "just works"? The only *really* significant improvement to legacy COM is the use of metadata in assemblies instead of type libraries, COM servers, and their clients being patched together using the Registry. What a nightmare this strategy was: class IDs, interface IDs, app IDs, type library IDs, ... !

What MS has done is to have simplified using the underlying COM technology by putting a managed layer on top of it (shades of VB), but disguise it as something new and cool, accompanied by a programming language that purports to be the successor of C++. In reality, C# (and its integration with .NET) is more or less Java + VB with a C++ paint job on top. It didn't take long for C++ developers (who were almost all enthralled by it initially) to realise that C# is really no match for C++. Just look at the new additions to C# (and .NET) - things like Generics. Any C++ programmer worth his or her wage will tell you that after having used templates and policy based programming techniques, they wouldn't consider going back to single inheritance and casts-fest.

MS guys are not stupid - that's why they got to where they are. They take whatever they see out there that's good, shrink wrap it, put a fancy label on it, and sell it as their own. They saw C++ developers converting to Java and they knew they had to do something about it. They couldn't highjack Java - Sun wasn't going to take that lying down - and VB wasn't the answer because it was too tainted. C++ was too difficult for most beginners and also too much of a challenge for a managed environment. Long live C# !

Don't get me wrong. I use C# in my development; a lot - especially in front-end work. With its tight integration with .NET and forms-based U/I (VB anyone?) it certainly makes for a more productive technology than C++ with make-shift libraries (don't get me started on MFC!) ATL for COM development is great, but it's not for the fainthearted. That's where the problem was all along: COM is great, if you look at its design (really elegant concepts - that's why the .NET environment emulates it so closely), but it was a pain in the behind for most developers to come to terms with. VB made it look easy, but no C++ programmer was going to convert to VB to do COM programming. On the other hand, doing it in C++ was quite a challenge. And while ATL 3.0 and VS6 were a big step forward, it was still rather difficult for most C++ developers. On one hand you had an elegant interface based design concept (COM) and on the other you had a policy-based library meant to assist you to build your own systems. Too much to swallow all in one go, if you ask me – at a time when most C++ programmers were only just beginning to discover STL.

Anyway, this is all off-topic, and I should stop before I start a(nother) war on the topic.

Radu
0

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now