Component-Based Architectural Style

Component-based architecture describes a software engineering approach to system design and development. It focuses on the decomposition of the design into individual functional or logical components that expose well-defined communication interfaces containing methods, events, and properties. This provides a higher level of abstraction than object-oriented design principles, and does not focus on issues such as communication protocols and shared state.

The key principle of the component-based style is the use of components that are:

• Reusable. Components are usually designed to be reused in different scenarios in different applications. However, some components may be designed for a specific task.
• Replaceable. Components may be readily substituted with other similar components.
• Not context specific. Components are designed to operate in different environments and contexts. Specific information, such as state data, should be passed to the component instead of being included in or accessed by the component.
• Extensible. A component can be extended from existing components to provide new behavior.
• Encapsulated. Components expose interfaces that allow the caller to use its functionality, and do not reveal details of the internal processes or any internal variables or state.
• Independent. Components are designed to have minimal dependencies on other components. Therefore components can be deployed into any appropriate environment without affecting other components or systems.

Common types of components used in applications include user interface components such as grids and buttons (often referred to as controls), and helper and utility components that expose a specific subset of functions used in other components. Other common types of components are those that are resource intensive, not frequently accessed, and must be activated using the just-in-time (JIT) approach (common in remoting or distributed component scenarios); and queued components whose method calls may be executed asynchronously using message queuing and store and forward.

Components depend upon a mechanism within the platform that provides an environment in which they can execute, often referred to as component architecture. Examples are the component object model (COM) and the distributed component object model (DCOM) in Windows; and Common Object Request Broker Architecture (CORBA) and Enterprise JavaBeans (EJB) on other platforms. Component architectures manage the mechanics of locating components and their interfaces, passing messages or commands between components, and—in some cases—maintaining state.

However, the term component is often used in the more basic sense of a constituent part, element, or ingredient. The Microsoft .NET Framework provides support for building applications using such a component based approach. For example, this guide discusses business and data components, which are commonly code classes compiled into .NET Framework assemblies. They execute under the control of the .NET Framework runtime, and there may be more than one such component in each assembly.

The following are the main benefits of the component-based architectural style:

• Ease of deployment. As new compatible versions become available, you can replace existing versions with no impact on the other components or the system as a whole.
• Reduced cost. The use of third-party components allows you to spread the cost of development and maintenance.
• Ease of development. Components implement well-known interfaces to provide defined functionality, allowing development without impacting other parts of the system.
• Reusable. The use of reusable components means that they can be used to spread the development and maintenance cost across several applications or systems.
• Mitigation of technical complexity. Components mitigate complexity through the use of a component container and its services. Example component services include component activation, lifetime management, method queuing, eventing, and transactions.

Design patterns such as the Dependency Injection pattern or the Service Locator pattern can be used to manage dependencies between components, and promote loose coupling and reuse. Such patterns are often used to build composite applications that combine and reuse components across multiple applications.

Consider the component-based architectural style if you already have suitable components or can obtain suitable components from third-party suppliers; your application will predominantly execute procedural-style functions, perhaps with little or no data input; or you want to be able to combine components written in different code languages. Also, consider this style if you want to create a pluggable or composite architecture that allows you to easily replace and update individual components.

⇐ Предыдущая12345678Следующая ⇒

Поделиться: