In order to use LightSpeed effectively it is useful to a have a reasonable understanding of the framework’s underlying architecture. The following sections provide a high-level discussion of the architecture of LightSpeed and also describe some of the foundational design patterns underpinning it’s design.
LightSpeedContext Class
A central object within the framework is the LightSpeedContext static class. The class is primarily a central registry for shared configuration and services. The following class diagram provides a visual view of LightSpeedContext and some of it’s key properties.
LightSpeedContext Class Diagram
The Repository
The Repository class is a static class representing the LightSpeed implementation of the well-known Repository pattern (see below). Internally, this class forwards requests to an instance of an implementation of the IUnitOfWork interface. To obtain the current IUnitOfWork instance, Repository uses an internal UnitOfWorkHolder class. This holder class determines how units of work are scoped. Currently, two scoping strategies are supported. If LightSpeed detects an Http Context, it employs a session-per-request scoping strategy using the System.Web.HttpContext.Items collection. Alternatively, a thread-scoped strategy is used. These classes are displayed in the following diagram.
Repository Class Diagram
The Entity Framework
LightSpeed also includes a base Entity framework that assists in the creation of effective .NET domain models. Central to the framework is of course the Layer Supertype Entity<TId> base class. This class handles, among other things, state tracking and validation and also implements the key databinding interfaces: IEditableObject, INotifyPropertyChanged and IDataErrorInfo. Other key classes include EntityCollection and EntityHolder which are used to declare one-to-many and many-to-one or one-to-one associations respectively. The class diagram below shows the key classes making up the LightSpeed entity framework.
Entity Framework Class Diagram
Design Patterns in LightSpeed
LightSpeed employs many common and well-known best-practice design patterns.
Unit of Work
Perhaps the pattern most central to LightSpeed is the Unit of Work pattern:
Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.
Roughly speaking a unit of work is just a logical collection of pending database operations corresponding to a business transaction. The process of updating a database with the changes in a unit of work is often called a “Flush”. In LightSpeed, the implementation of this pattern provides a number of benefits including:
- Entity state changes are tracked automatically.
- Connection handling is an efficient, acquire-late, release early strategy.
- LightSpeed employs very efficient SQL batching strategies reducing database round-trips.
- Each unit of work uses an internal Identity Map which acts as a unit of work local entity cache.
Unit of Work Mechanics provides more detailed information about how LightSpeed implements the Unit of Work pattern.
Repository
Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.
LightSpeed’s Repository class acts as the primary gateway API to the underlying data store and exposes methods such as Repository.Add, Repository.Remove, Repository.SaveChanges and various Repository.Find methods. A key driver in the design of the Repository class was usability. The class therefore exposes a static API and internally manages unit of work scoping and lifetimes.
Other Patterns
Other design patterns at work in or facilitated by LightSpeed include: