How To: Design Business Components

J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat.

Applies To

  • Business components
  • Business Layer.

Summary

There are several types of business components you will use when designing and implementing an application. Examples of these components include business process components, utility components, and helper components.

Contents

  • Objectives
  • Overview
  • Summary of Steps
  • Step 1 – Identify Business Components Your Application Will Use.
  • Step 2 – Make Key Decisions for Business Components.
  • Step 3 – Choose Appropriate Transaction Support.
  • Step 4 – Choose a Design for Handling Business Rules.
  • Step 5 – Identify Patterns That Fit the Requirements.
  • Additional Resources

Objectives

  • Learn about different types of business layer components.
  • Learn how to make decisions related to business component location, coupling, and interaction.
  • Learn about transaction support, and learn how to choose an appropriate model.
  • Learn how business components can be used for rule processing.
  • Learn how to identify and choose patterns that support your business processing requirements.

Overview

This article starts with an overview of different business components that you will find in most application designs. The primary focus is on business process components. The article shows how different aspects of your application design, transactional requirements, and processing rules affect the design you choose. Once you have an understanding of the requirements, the final step focuses on design patterns that support those requirements.

Summary of Steps

  • Step 1 – Identify Business Components Your Application Will Use.
  • Step 2 – Make Key Decisions for Business Components.
  • Step 3 – Choose Appropriate Transaction Support.
  • Step 4 – Choose a Design for Handling Business Rules.
  • Step 5 – Identify Patterns That Fit the Requirements.

Step 1 – Identify Business Components Your Application Will Use

Within the business layer, there are different types of components that you may need to create or use to handle business logic. The goal of this step is to define those components and discover considerations that can be used to identify components required by your application. Many of these components can be found in the Microsoft .NET Framework, through some will need to be defined by your application.
  • Business Process components are used to handle requests from the presentation tier, service interface, workflow components; or from other business components. These components are responsible for handling the request and, in most cases, implement business rules. The rules could be encapsulated directly within the business components, or they could be retrieved from an external source such as a business rules engine.
  • Business Workflow components are used to provide operations that support workflow requirements. They work with business process components that are used to instantiate and perform operations on workflow components. For more information on business workflow components, see “How To: Design Business Workflow Components”.
  • Utility components implement common tasks that are required throughout an application. For instance, you might have a utility class that provides configuration support. In many cases, you might want to make the utility class operations static so that you can access them without instantiating the class. When using static operations, components should not use data that is shared across threads unless you plan to implement thread-safe code.
  • Helper classes typically wrap other classes to provide operations that simplify coding tasks. For example, you might want to wrap the serialization of objects into XML strings by creating a helper class that uses the XmlSerializer and supporting objects to perform the serialization.

Consider using business process components:
  • If your application has business rules that must be handled in the business layer.
  • If your application must handle dynamic behavior with business logic.

Consider using workflow components:
  • If you need to process multiple steps that depend on external resources.
  • If you need to support an approval process for documents.
  • If you have business rules that are dependent on the outcome of other business rules.
  • If you have a process that depends on the state of other components or documents.

Consider using utility components:
  • If you have common operations, such as logging, that must be accessible across all layers of your application.
  • If you have configuration data that must be accessible to application code.
  • If you have common operations, such as creating a hash with a specific salt value, that must be available throughout the application.

Consider using helper classes:
  • If you want to wrap multiple components into common interface. For example, an XmlSerializationHelper that wraps the XmlSerializer, Reader, and StringBuilder objects to perform object to XML string serialization.
  • If you want to extend the functionality of existing helper components.

CheckPoint

Before you finish this step, you should be able to answer the following questions:
  • Will your application benefit from the use of business process components?
  • Does your application need to support business workflow components?
  • Have you identified utility components that will support your application?
  • Can you benefit from the use of helper components?

Step 2 – Make Key Decisions for Business Components

The overall design and type of application you are creating plays a role in the business process components that it will use to handle requests. For example, business components for a Web application usually deal with message-based requests, while a Windows Forms application will typically use event-based requests to interact directly with business components. In addition, there are other factors to consider when working with different application types.

When it comes to making decisions about the design of your business components, some considerations are common and some are unique to an application type. As a result, the following application types will be considered:
  • Rich Client represents an application that is hosted on the client. The desktop may be anything from a Windows desktop to a mobile device. This type of application may include self-contained commercial products or distributed applications that are occasionally connected. The key differentiator is that a Rich Client must be able to run directly in the host environment without a dependency on the browser.
  • Services are commonly referred to as Web services. However, with the introduction of the Windows Communication Foundation (WCF), a service is not dependant on Web protocols. The best way to think about a service is something that provides a programmatic interface that is consumed by other applications using message-based protocols such as SOAP.
  • Web represents an application that is hosted within a Web browser. The client can be anything from plain HTML generated by a Web server and rendered in the browser, to a Silverlight application that runs within a browser plug-in.

Key decisions you must make with business components include:
  • Location – Should business components be located on the client, or on an application or Web server?
  • Coupling – How will presentation components interact with business components? Should you use tight coupling where the presentation components have direct knowledge of the business components, or loose coupling where an abstraction is used to hide details of the business components?
  • Interaction – If the business components are located on an application or Web server, how will presentation components interact with the business components? How reliable does the interaction need to be? How will you handle occasionally connected scenarios?

Consider locating business components on the client:
  • If you have a stand-alone Rich Client or a Rich Internet Application (RIA).
  • If you want to improve performance.
  • If you are using a domain model design for business entities.

Consider locating business components on an application server:
  • If you need to support multiple client types with common business logic.
  • If business components require access to resources not accessible from the client.

Consider tight coupling between presentation and business components:
  • If you have a Rich Client or RIA application with both sets of components located on the client.
  • If you are using a domain model design for business entities.

Consider loose coupling between presentation and business components:
  • If you have a Rich Client or RIA application with business components located on an application server or Web server.
  • If you are not using a domain model design for business entities.
  • If you have a large application with functionality separated into layers.
  • If you want to improve testability through the use of abstract interfaces.

Consider using message-based interactions:
  • If you are designing the interface for a service.
  • If you are designing a Web application with loose coupling between the presentation and business layers.
  • If you have a Rich Client or RIA application that is occasionally connected to an application server or Web server.

Consider Idempotency, which is the ability to ignore duplicate requests:
  • If you are designing a service application.
  • If you are designing a message-based application that uses a messaging system such as Microsoft Message Queuing.
  • If you are designing a Web application where a long running process may cause the user to attempt the same action multiple times.

Consider guaranteed delivery:
  • If you are designing a message-based application that uses a messaging system such as Microsoft Message Queuing.
  • If you are designing a service that uses message routers between the client and service.
  • If you are designing a service that supports fire-and-forget operations where the client sends a message without waiting for a response.

CheckPoint

Before you finish this step, you should be able to answer the following questions:
  • Where will you locate the business components?
  • What type of coupling will you use between presentation and business components?
  • Should you use message-based interaction between presentation and business components?
  • Does your application need to support Idempotency?
  • Does your application need to support guaranteed delivery?

Step 3 – Choose Appropriate Transaction Support

Business process components are responsible for managing any transactions that may be required. However, the first step is to determine if transaction support is required. Transactions are used to make sure that a series of actions executed against a one or more resource managers, such as databases and message queues, are completed as a single unit independent of other transactions. If any single action in a series fails, then all other actions must be rolled back. For example, you might have an operation that updates three different tables using multiple business process components. If one of those updates fails, but two succeed, the data source will be in an inconsistent state; which means that you now have invalid data on which other operations may be dependent.

The following options are available for implementing transactions:
  • System.Transactions uses business process components to initiate and manage transactions. Introduced in .NET 2.0 along with the Lightweight Transaction Manager (LTM) used for dealing with non-durable resource managers or one durable resource manager. Requires explicit programming against the TransactionScope type. Can escalate the transaction scope and delegate to a Distributed Transaction Coordinator (DTC) if more than one durable resource manager is enlisted in the transaction.
  • WCF Transactions were introduced in .NET 3.0 and built on top of System.Transactions available in .NET 2.0. They provide a declarative approach to transaction management that is implemented using a range of attributes and properties, such as TransactionScopeRequired, TransactionAutoComplete, and TransactionFlow.
  • ADO.NET Transactions are available since .NET 1.1 and require the use of business process components to initiate and manage transactions. They use an explicit programming model where developers are required to manage transactions in code.
  • Database transactions are used for very simple transaction management that can be incorporated into stored procedures, which will also simplify your business process design. If transactions are initiated by business process components, the database transaction will be enlisted in the transaction created by the business component.

Consider using System.Transactions:
  • If you are developing new applications that require transaction support.
  • If you have transactions that span multiple resource managers
  • If your application will be deployed into environments where .NET 3.0 is not available.

Consider using WCF Transactions:
  • If you are required to support transactions when interacting with WCF services.
  • If you are developing a new application that will be deployed into an environment that supports .NET 3.0.

Consider using ADO.NET Transactions:
  • If you are extending an application that already uses ADO.NET Transactions.
  • If you are using ADO.NET providers for database access and the transactions are limited to a single database.
  • If you are deploying your application into an environment that does not support .NET 2.0.

Consider using database transactions:
  • If you are developing stored procedures that encapsulate all of the changes that must be managed by a transaction.
  • If you have multiple applications that use the same stored procedure, and transaction requirements can be encapsulated within the stored procedures.

CheckPoint

Before you finish this step, you should be able to answer the following questions:
  • Do you need to implement transaction support?
  • Can you take advantage of the transaction support available in .NET 3.0?
  • Do you need to implement transactions that span multiple resource managers?
  • Are you required to support transactions with WCF services?
  • Can you implement transactions in the database with stored procedures?

Step 4 – Identify how Business Rules are handled

Managing business rules can be one of the more challenging aspects to application design. Generally, you should always keep business rules within the business layer. However, exactly where in the business layer should they go? You can use business process components, business rule engines, or use a domain model design with rules encapsulated in the model.
  • Business Process Components are used when you want to decouple business rules from business entities, or the business entities you are using do not support the encapsulation of business rules. They can be used to handle simple rules or very complex rules, depending on the design pattern used to implement the business process components.
  • Business Rules Engine provides a way for non-developers to establish and modify rules, but they also add complexity and overhead to an application and should only be used where appropriate. In other words, you would only use a rules engine if you have rules that must be adjusted based on different factors associated with the application.
  • Domain Model Design can be used to encapsulate business rules within business entities. However, a domain model design can be difficult to get right, and tends to focus on a specific viewpoint or context.

Consider using business process components:
  • For tasks or document-oriented operations in Web applications or services.
  • If you are not implementing a domain model design for business entities.
  • If you are using an external source that contains the business rules.

Consider using a business rules engine:
  • If you have volatile business rules that must be modified on a regular basis.
  • If you want to allow business users to manage and update rules.

Consider encapsulating rules in a domain model:
  • If you have a Rich Client or RIA application where the business components are deployed on the client, and the domain model entities are initialized and persisted in memory.
  • If you have a small domain model that can be maintained within the session state associated with Web or service applications.

CheckPoint

Before you finish this step, you should be able to answer the following questions:
  • Are you using a domain model design for business entities where the rules can be encapsulated within the domain entities?
  • Do you have volatile business rules that change often?
  • Do you need to provide the ability for business users to manage and define business rules?

Step 5 – Identify Patterns That Fit the Requirements

Behavioral patterns are based on observing the behavior of a system in action and looking for repeatable processes. With business process components the type of patterns you might use are usually behavioral design patterns. In other words, patterns that are focused on the behavior of an application at the design level.

There has been a lot of work done in identifying and defining patterns that occur in different types of applications and in different layers of an application design. It is not feasible to try to learn all of the patterns that have been defined; however, you should have a good understanding of different pattern types and be able to examine your scenario to identify behavior that could be expressed as a pattern.

The following patterns are commonly used with business components:
Pattern Recommendation
Transaction Script Recommended for basic CRUD operations with minimal business rules.
Transaction script components would also initiate transactions
With this pattern
Adapter Allows classes that have incompatible interfaces to work together.
Allows developers to implement sets of polymorphic classes that provide alternative implementations for an existing class.
Command Recommended for Rich Client applications with menus, toolbars, and hot-key interactions that are used to execute the same commands against different components.
Can also be used with the Supervising Controller pattern to implement commands.
Chain of Responsibility Used to chain request handlers together so that each handler can examine the request and either handle it or pass it on to the next handler in the chain.
An alternative to "if, then, else" statements, with the ability to handle complex business rules.
Decorator Used to extend the behavior of an object at runtime.
Allows you to add or modify operations that will be performed when executing a request.
Requires a common interface that will be implemented by decorator classes.
Decorator classes can be chained together to handle complex business rules.
Dependency Injection Allows you to create and populate members (fields and properties) of objects using a separate class, which usually creates these dependencies at runtime based on configuration files.
Configuration files are defined as containers that specify the mapping or registrations of object types.
Application code can also be used to define the mapping or registration of objects.
Flexible approach to modifying behavior and implementing complex business rule.
Façade Very common pattern used to provide coarse-grained operations that unify the results from multiple business process components.
Typically implemented as a remote façade for message-based interfaces into the business layer.
Used to provide loose coupling between presentation and business layers.
Factory Common pattern used to create object instances without specifying the concrete type.
Requires objects that implement a common interface or extend a common base class.


While this list represents many of the common patterns you might use with business components, there are many other patterns associated with business components. The main goal when choosing a pattern is to ensure it fits the scenario and does not add more complexity than necessary.

Additional Resources

Last edited Dec 17, 2008 at 8:28 PM by prashantbansode, version 3

Comments

No comments yet.