views:

72

answers:

2

I want to know purpose of .NET and COM ,

  • Is .NET has the same purpose as that of COM ? Because main purpose of COM is to allow language interoperability so as that of .NET ?
  • If so Why many companies still using COM for their development projects ?
  • Is it worth learning COM when we can use .NET ?
+3  A: 
  1. One of the reasons for COM was that if you developed a C++ library in Borland C++ builder you couldn't use it in VB6. But you couldn't use it in VC6 either (COM is way older than these products btw). So COM is a C like protocol for interopability between applications and libraries. .NET allows for interopability between managed applications. If you want to interop with C++ use C++/CLI. But what do you do if you have a legacy COBOL application that wish to use a .NET component? Exposing that component as COM would be one way to approach it. Exposing a C like API is another way.

  2. Not suprisingly since COM has been around since the late 80s (I think) alot of business value has been built on COM tech. It makes no business sense and is way too costly and risky to rewrite working applications to .NET just for the fun of it. So companies that have to maintain legacy applications naturally have lot of COM based tools and apps.

  3. It all depends on your business case. Can you get away with .NET platform only I guess you don't need to know COM (although COM is used by .NET platform and sometimes errors leak through). If you are using COM libraries exposed by the operating system or other libraries it makes sense knowing some basic COM rules.

PS. I like COM. I don't like the registration part, I don't enjoy DCOM and I think the COM apartments in the end has confused more than it helped developers (it was originally developed to help developers avoid race conditions and related issues). But the core COM is quite decent. Some fights have been over "Is COM OO?" but that boils down to why does we use OO? IMO to give encapsulation. So the question is then: "Does COM give good encapsulation?". The answer is yes (IMO).

PS. Last I checked Firefox used something called XPCOM which looked alot like COM to me.

FuleSnabel
I use to joke with my boss that C++ + COM competence is soon like COBOL competence. There's not much jobs but even less people that knows it, so we will be able to set our own salaries as there's just so much business value tied to this technology.
FuleSnabel
+1  A: 

You may find this Channel9 video interesting. Juval Lowy, a Microsoft COM/WCF expert says it may make sense to may every class a WCF service, akin to DCOM

http://channel9.msdn.com/shows/ARCast.TV/ARCastTV-Every-Class-a-WCF-Service-with-Juval-Lowy/

That link argues that compromises are made in terms of performance for ease of use and ease of development over time. As this trend continues, the need for low-level COM/DCOM programming is reduced. Of course this doesn't cover every scenario, but it does cover many non critical business needs.

Should you learn COM? As it stands today WCF (and other parts of .NET) is based on COM. Having an understanding of COM will help troubleshoot those low-level issues that crop up, but unless it's your primary or secondary career focus, I wouldn't spend a lot of time on it.

MakerOfThings7
I will watch this but my knee jerk reaction is: No, not again!!!Making every class a COM class seemed like a brilliant idea at the time but it's really a mess due to increasing the cost of development alot. Also do I want to expose all my internal classes to our users? And with DCOM it flooded the network with pings.With webservices I think it's even worse as a the interface of a webservice you don't design in the same way as a class you have in memory (a webservice often uses chunky methods to reduce call overhead). Also a webservice might disappear whenever, an inmemory object won't.
FuleSnabel
@FuleSnabel I don't disagree with several of your points when talking about some of the more chatty bindings... Perhaps one thing that is preventing the theory from becoming reality is the need to make all private interfaces public. One way to fix that could be to make the "Int" class a WCF service. If that were to occur, then maybe you can keep your privates private. Also, you may want to look at the namedpipes binding for more efficiency, but the overall point is to easily allow for parallel programming using WCF at the cost of per-thread efficiency.
MakerOfThings7