Architecting .NET Applications for the Enterprise

Microsoft® .NET: Architecting Applications for the Enterprise (amazon)

A great book, I think, on software architecture using the .NET framework

The first part of the book is on Principles of software architecture. The seconds part is on the "Design of the System". This second part is then divided into a number of chapter. Each chapter is dedicated to one layer of the system. Business layer, Service layer, Data Access Layer etc.

My notes here are on the design of the business layer. The authors presented a number of patterns starting with the simplest and progressing to the most complex one that's suited to applications where the business logic involves much more that data insertion and retrieval.

BLL Patterns

Transaction Script Pattern

Think of an ASP.NET page with controls whose events are handled by code-behind (or MVC actions) code. The code then interacts with data store according following a script of known steps. This is a very simple pattern with no object-oriented design.

Command Pattern

The authors then talk about the command pattern as one step above the TS pattern. Each action that the system does is incapsulated in a class with a common interface. What's interesting here is that since actions are represented as classes, actions or a series of them that participating in a transaction, can be serialized.

Table Module Pattern

What's interesting about this pattern is that the BLL logic is grouped into components each of which deal with one entity. The component or class does not represent the entity but rather serves as a gateway to the table holding the instances of that entity in the database. Code following this pattern tends to be heavy on DataSet or similar data container but not a generic .NET container. DataSets are awful. 

Table Data Gateway Pattern

In this pattern, another layer is added between the BLL logic and the code directly talks to the database, hence Gateway.

Active Record Pattern

Each data entity is represented by class. Unlike the TM pattern, what is represented here is the individual rows and not the entire table. This allows for use of .NET generic containers. 

A class represents a row and all the logic that can be done on that data. The data handling (read,write, update and deleted) can be done either with this class or in separate DAL specific class.

The simplicity of this pattern, its cleanliness and its strongly-typed nature of representing entities make it a good choice for applications that are not very complex. Have said that however, I recommend taking a look at http://misko.hevery.com/2009/06/29/active-record-hard-to-test/.

Interestingly, the authors talk about LINQ-to-SQL and how it can be considered an Active Record pattern implementation.

Domain Model Pattern

When the complexity of a system grows and business logic involves operations that far exceed interactions with the database, the DM pattern is ideal. The focus here is on modeling the domain problem into a set of interconnected objects. The focus is also on the logic and interactions between these objects with no regard (at least at the BLL) to how data is persisted. 

Summary

A few patterns caught my interest while reading the Microsoft® .NET: Architecting Applications for the Enterprise. These patterns are primarily used when designing the business logic layer. Patterns discuss include, Transaction Script, Table Module, Active Record and Domain Model.