Of course, Visual Basic alone wasn ’ t the only thing preventing enterprise patterns from making their way into Microsoft code. Some tend to think that Microsoft ’ s previous software development platform had much to do with this as well. Before we had the neat and clean world of .NET, most C and C++ programmers were forced to use its predecessor, the Component Object Model, or COM. COM is a Windows - specific technology that allowed for components from different applications to communicate and interoperate with one another. Specifically, it is an interface standard that facilitates inter – process communication and object creation within any application, service, or system that supports the technology. COM patterns drive most objects that were used in Visual Basic programming, many of which are still in use on the Windows operating system. However, many developers felt that implementing COM introduced complexity that wasn ’ t well suited to business applications. At the heart of every COM object lives a single common interface named IUnknown . This interface defines three key COM method definitions: AddRef , Release , and QueryInterface , each of which is used to manage objects in memory and communicate between objects.
As an object - oriented pattern, COM was well orchestrated and seemed to deliver on some of the goals that drive enterprise development. However, not everyone embraced COM programming. Implementing IUnknown generally meant that you had to write your program in a lower - level programming language such as C or C++. Since most Microsoft developers preferred to develop with RAD tools and languages, direct COM usage was hard to come by. Instead, COM - powered technologies such as Object Linking and Embedding (OLE) and ActiveX were provided to RAD programmers as a means to leverage COM objects without all of the hassle of the IUnknown plumbing. Unfortunately, COM - powered technologies were much heavier than straight COM. They introduced overhead and had a tendency to run more slowly than systems that implanted COM directly. Additionally, integration with other platforms became mostly impossible. COM objects became synonymous with Microsoft objects. As a pattern it didn ’ t accommodate interoperability with non - Windows platforms. So, while COM was a fine pattern for designing enterprise architectures, it was only used as a means to define the Microsoft API itself. Precious few organizations employed the COM pattern directly within their own code.
Source of Information : Wrox Professional Enterprise dot NET
As an object - oriented pattern, COM was well orchestrated and seemed to deliver on some of the goals that drive enterprise development. However, not everyone embraced COM programming. Implementing IUnknown generally meant that you had to write your program in a lower - level programming language such as C or C++. Since most Microsoft developers preferred to develop with RAD tools and languages, direct COM usage was hard to come by. Instead, COM - powered technologies such as Object Linking and Embedding (OLE) and ActiveX were provided to RAD programmers as a means to leverage COM objects without all of the hassle of the IUnknown plumbing. Unfortunately, COM - powered technologies were much heavier than straight COM. They introduced overhead and had a tendency to run more slowly than systems that implanted COM directly. Additionally, integration with other platforms became mostly impossible. COM objects became synonymous with Microsoft objects. As a pattern it didn ’ t accommodate interoperability with non - Windows platforms. So, while COM was a fine pattern for designing enterprise architectures, it was only used as a means to define the Microsoft API itself. Precious few organizations employed the COM pattern directly within their own code.
Source of Information : Wrox Professional Enterprise dot NET
|
|
0 comments
Post a Comment