02 - Business Layer Considerations

The below figure shows how the Business Layer fits into common application architecture.

Below are the Business Layer Considerations to be taken before designing business layer.

1. Prefer a Stateless Design
2. Seperation of Concern
3. Identify the Consumers
4. Avoid Tight Coupling between layers.
5. Caching
6. Concurrency and Transactions
7. Data Access
8. Deployment Considerations

Prefer Stateless Design

Ideally, in a Stateless Design, the lifetime of your business objects is tied to the lifetime of a single request. This gives you below advantages.

Pros:

·         Minimize Resource Contention – Thus Increase Performance -  Stateless Design, make you ensure that your business objects do not hold onto shared resources across calls.  This helps reduce resource contention and increase performance.

·         Avoid Server Affinity – Thus Increased Scalablity - Stateless objects also make it easier for you to ensure that you do not introduce server affinity, which restricts your scale-out options.

If you use Stateful Design using Singleton objects, you should store state outside of the object in a resource manager, such as a SQL Server database, and rehydrate the object with state before servicing each request.

Seperation of Concern:

When designing a business layer, the goal of a software architect is to minimize the complexity by separating tasks into different areas of concern.

For example, Business Processing, Business Workflow, and Business Entities all represent different areas of concern. Within each area, the components you design should focus on that specific area and should not include code related to other areas of concern.

Identify the Consumers

This help yoi in determining, how you expose you business layer.

For example, if your business layer will be used by your presentation layer and by an external application, you may choose to expose your business layer through a Web/WCF Service.

Avoid Tight Coupling between layers.

Use abstraction when creating an interface for the business layer.

·         At Business Layer: The abstraction can be implemented using

·         Public Object Interfaces,

·         Common Interface Definitions,

·         Abstract Base Classes, or

·         Messaging

·         Separate interface from implementation – By providing Facades.

·         For Web applications - Consider a Message-based communication between the presentation layer and the business layer

Caching

When designing a caching strategy, consider below:

·         Consider how Web farm deployment will affect the design of your business layer caching solution. If a request can be handled by any server in the farm you will need to support the         Synchronization Of Cached Data that can change.

·         Design Cache Implementation, if you want the Cache to be per-user specific.

Concurrency and Transactions

When designing for concurrency and transactions, it is important to identify the Appropriate Concurrency Model – Optimistic / Pessimistic and determine how you will manage transactions.

Optimistic Concurrency (Time-Stamp Based) -  Locks are not held on data and updates require code to check, usually against a timestamp, that the data has not changed since it was last retrieved.

Pessimistic Concurrency - Locks are held on data and thus cannot be updated by another operation until the lock is released.

When designing for concurrency and transactions, consider the following guidelines:

•        Use Connection-Based Transactions when accessing a single data source.

•        Consider Transaction Boundaries, so that retries and composition are possible.

•        Where you cannot apply a commit or rollback, or if you use a long-running transaction, implement Compensating Methods to revert the data store to its previous state should an operation within the transaction fail.

•        Avoid holding locks for long periods; for example, when executing long-running atomic transactions or when locking access to shared data.

•        Choose an appropriate Transaction Isolation Level, which defines how and when changes become available to other operations.

Data Access

Designing an effective data access strategy for your business layer is important to maximize maintainability and the separation of concerns.

Failing to do so can make your application difficult to manage and extend as business requirements change.

An effective data access strategy will allow your business layer to adapt to changes in the underlying data sources.

When designing a data access strategy, consider the following guidelines:

• Avoid Mixing data access code and business logic within your business components.

• Avoid Directly Accessing the database from your business layer. Consider using a separate DAC layer for access to the database. Thus the Loose Coupling is achieved.

Deployment Considerations

When deploying a business layer, you must consider performance and security issues within the production environment.

When deploying a business layer, consider following guidelines:

•        Prefer Non-Distributed deployment, to maximize application performance.

•        If Distributed deployment, consider using TCP protocol to improve performance of the application.

•        Use IPSec to protect data passed between physical tiers for all business layers for all applications.

Hope this helps.

Regards,

Arun Manglick