This is in continuation to my previous post Silverlight 2 Best Practices – III, where the focus was what should be and what should not be done while developing a Silverlight Application. It was purely from a developer’s perspective.  In this post, we would consider designing the ‘Data Access Layer’

Designing Data Access Layer

In most of the web applications, data access layer comprises of 3 components:

• Utilities – that help in accessing data components. Example, converters and alike
• Data components – core components that access the data sources
• Service Agents – this is an additional layer (proxies) over the services that are called from DAL. Mostly done to bring an additional isolation, entity mapping, or service-specific conversions.

 

Here, we will concentrate on ‘Data Components’ as the other two components are relatively easier to design and readily available as well or tools can generate them too.

 

Managing Connections

 

Which connection remains open/closed should be monitored by a single interface. All calls should be redirected to a single function which would manage opening, closing of a connection and its timeout.  Connections can be cached for smallest duration of time to increase performance – however, security should of sensitive information like hostname, password should be taken care of as well.

 

The application should also take care that the fan-out does not reach.  This will ensure that no user gets a timeout error.

 

Design should enable switching between two replicas of data sources. This is most important during maintenance shutdown, or release of a newer version of application, or when database crashes.

 

Exception Handling

 

DAL should ideally handle all exceptions and should not crash in any scenario; however all CRUD operations MUST be handled by DAL.

 

Exceptions concerning data access (data source unavailable, timeout, etc) should be handled by DAL; while other business related errors should be returned in an Error object in a serialized format.

 

Profile for best performance

 

In Internet applications DAL is the most accessed-by, making it prone to crashes and security risks.  Profiling of DAL is must to gauge the impact of high number of concurrent users.  Also, in such scenario DAL should be prevented against attacks from hackers.  Any other source of access should be give least privilege and only the web application should be at a higher privilege.

 

Consider using Batch Processes to reduce round-trip to database server.

 

 

 

Managing data

 

One of the common problems seen in many projects while doing profiling exercises is degraded performance due to improper data handling.  So let us see some important guidelines:-

 

• If the system involves lot of documents and image storing – prefer to store them in BLOB, than on a file system
• Avoid Outer Joins wherever possible
• Use of cursors should not be preferred – use in-memory temporary tables instead.
• Open connections as late as possible.
• Use XML pameters for bulk inserts or updates – this will save execution time.
• Use parameterized SQL statements and typed parameters to mitigate security issues and reduce the chance of SQL injection attacks succeeding.
• Do not use string concatenation to build dynamic queries in the data layer.
• Use typed parameters as input values to the procedure and output parameters to return single values.
• Use optimistic concurrency with non-volatile data to mitigate the cost of locking data in the database

 

Dynamic Queries or Stored Procedure

 

1. For a small footprint application with lesser clients and few business rules, prefer Dynamic Queries. IF NO, STEP 2
2. Larger application, multiple clients – abstraction can be at
   1. Database level in Stored Proc – minimal code changes  
   2. DAL using patterns  - best till the schema does not change, can be debugged
   3. DAL using ORM – best till the schema does not change, can be debugged

 

ADO.NET Services

 

I would suggest a very good tutorial on MSDN. Click here to read through.

 

 

Now, let’s take a break from the best practices and create some Silverlight applications. You’ll soon see some small Silverlight applications that can help you ease your efforts.

 

Punit

MCTS – Sharepoint

MCP – .NET

This is in continuation to my previous post Silverlight 2 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, do these

 

1.    Identify ACTORS or CONSUMERS

2.    How these ACTORS will communicate to your business layer.

a.    Concurrency needs to be addressed for access to STATIC data.

b.    Long-running transactions should not LOCK the data.

3.    SECURITY requirements for business layer

a.    Apply AUTHENTICATION wherever required.

b.    Use SSO where appropriate.

4.      VALIDATION and EXCEPTION HANDLING strategies

a.    DONOT RELY on validations at presentation layer – reuse the VALIDATION logic.     

b.    Should NOT reveal sensitive information to the end user.

c.     Should NOT use exceptions for application logic.

d.    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-

 

1.    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.

2.    Domain Module Patter – this pattern is widely used for stateful application that has complex business rules.

3.    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.

 

Punit

MCTS – Sharepoint

MCP – .NET & SQL