Puneet Ghanshani

Chief Architect at Microsoft

7 minute read

This is in continuation to my previous post Silverlight Best Practices – I, where I talked about Design Considerations.  These design considerations were a bird’s view and the posts to come will explain these in detail.  In this post, I shall deal with the Business Layer, its components, steps to design these components, and design considerations.  This post can be considered not just for Silverlight Applications, but for other Web Applications as well.

Business Layer

 

Let us take on the parts of the business layer for those who are newbie

  1. Application Façade – layer that combines multiple business operations into single message based operation
  2. Business Components – Business Rules & Validations
  3. Entities – Used to pass data between business components
  4. Business Workflow – Multi-step and/or long-running business process

Design Considerations

 

Before you jump into designing of business layer, it is advisable to do these

 

  1. Identify ACTORS or CONSUMERS
  2. How these ACTORS will communicate to your business layer.
    1.  Concurrency needs to be addressed for access to STATIC data.
    2.  Long-running transactions should not LOCK the data.
  3. SECURITY requirements for business layer
    1.  Apply AUTHENTICATION wherever required.
    2. Use SSO where appropriate.
  4.  VALIDATION and EXCEPTION HANDLING strategies
    1. DONOT RELY on validations at presentation layer – reuse the VALIDATION logic.
    2. Should NOT reveal sensitive information to the end user.
    3.  Should NOT use exceptions for application logic.
    4.  Log SUFFICIENT detail from exceptions.

Authentication & Authorization Module Design

Authentication is not a mandate requirement and should be done if the Business Layer is to be used by several clients.  An easier said – public web services need authentication, but an application oriented service does not.

Consider IP filtering to restrict hacks and unauthorized usage or to have access only through the presentation layer.

For business decisions –role based or claim based authorization needs to be implemented.

Impersonation can screw-up your performance. So prefer avoiding it.

Business Components & Entities

Keep them light and encapsulated.  Do not mix data access logic and business logic. Break them into two assemblies. Volatile business rules ought to be kept in rules engine (Workflow, DROOLS.NET, etc)

Use ONLY CUSTOM objects as Business Entities, even if it means encapsulating only a string object.

Choose between the three patterns while designing these entities-

  • Table Module Pattern – this is typically used when database tables can represent entities.  This model is suited for large database applications or applications that use LINQ to SQL.
  • Domain Module Patter – this pattern is widely used for stateful application that has complex business rules.
  • XML – this is used for relatively smaller applications.

Serialize your objects if it requires passing between network boundaries.


Caching and Concurrency

Appropriate caching mechanism can speed up your performance by leaps and bounds by avoiding duplicate processing.  To avoid client delays, caching should be a background process.

Cache the data (non-sensitive ONLY) in a ready-to-use format.  In other words, data taken from cache should not necessarily require processing before use.  Caching resources should avoid locks due to threading.

Use connection based transactions to access single data source. Which means - a rollback should let you get back to previous state. When a rollback or commit cannot be applied (for processes that are long-running), then compensating methods should be in place. 

Logging and Audit Mechanism

Logging and Auditing cannot be compromised at an enterprise level application.  It can open doors to threats without getting noticed.  Auditing, if generated at granular level, can let us know precise time, IP, location of resource access.

One can use Enterprise Library or any other component to implement logging mechanism – but it needs to be centralized.   However unexpected failure of this centralized block should not cause stop the business functionalities.

Workflows

 

Windows Workflow is a great-gift by Microsoft to the technologies. Workflows – state machine or sequential - should be initiated on a separate thread for long-running process.  Faulty conditions should be handled as exceptions. 

Deployment

Towards the end, an incorrect deployment will surely not deliver excellent results. Use TCP protocol and SSL to support remote business layer in a safe manner.

 

The next to come in this series will be a post on what not to do in Silverlight while developing an application. This will focus on best practices that a developer needs to take care of.

 

You May Also Enjoy