I have created a whitepaper for Designing Modular Smart Clients using Composite Client Application Guidance. The paper provides architectural guidance for designing and implementing enterprise WPF/ silverlight client applications based on the Composite Application Guidance for WPF and Silverlight provided by the Microsoft Patterns & Practices group.
The Composite Application Guidance for WPF and Silverlight is a set of guidance designed to easily manage the complexities developing enterprise-level Windows Presentation Foundation (WPF) client applications and Rich Internet Applications (RIAs) with Silverlight. Composite WPF guidance helps design and build flexible client applications using loosely coupled, independently evolvable pieces that work together and are integrated into the overall application. This type of application is known as a composite application.
You can download the whitepaper from the below given links
The customer repository inherits the base repository and uses the data mapper instance for object creation. All the CRUD procedures defined in the first post of this series are called in this class. The query for accessing and persisting data in the relational model is formed in the Customer repository.
Mapping the data elements in the domain model and relational model for the customer entity functionality is implemented as part of the CustomerMapper class which inherits from the BaseMapper created in the previous sample. The customer mapper class contains code to convert data between these data models.
The overridden Construct method is responsible for this data conversion. Once the data mapper is ready, we’ll use this in the repository for data access. The data mapper is not exposed outside the repository.
Creating the repository for the sample
Martin fowler writes:
"A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to Repository for satisfaction. Objects can be added to and removed from the Repository, as they can from a simple collection of objects, and the mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes. Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer. Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers."
Each entity in a domain layer defines a repository for data access operations. In our sample we have one entity (Customer). We’ll define a repository for the customer entity and write some test cases to demonstrate the functionality. The repository interface defines the CRUD operations required for our sample.
T GetById(Key id);
IList GetAll();
void Insert(T entity);
T Update(T entity);
void Remove(Key id);
I have created a base repository class which will be used as the base class for entity specific repositories and implements the common functionality.
protected T FindOne(DbCommand command)
{
T entity = new T();
using (IDataReader reader = ___Database.ExecuteReader(command))
{
if (reader.Read())
entity = Mapper.Construct(reader);
}
return entity;
}
protectedIList Find(DbCommand command)
{
IList entityCollection = default(List);
using (IDataReader reader = ___Database.ExecuteReader(command))
As mentioned in the previous post Data Mapper is a layer to hide database access from your domain objects. As a recommendation data mapper should not be exposed to the business logic layer. All calls to the data mapper should be routed via a Repository that should make use of the data mapper for object creation. The data mapper will have access to the domain model/ entities for object creation. In this post, we’ll see how to create a data mapper implementation in C#.
Before looking into the data mapper, we’ll create our first business entity, Customer. Every business entities in our sample inherit from a base entity that holds the common properties for key, versioning and tracking. The Customer entity is defined as
publicclassBaseEntity
{
public T Id { get; set; }
publicDateTime CreatedDate { get; set; }
publicDateTime ChangedDate { get; set; }
publicbyte[] Version { get; set; }
}
publicclassCustomer :BaseEntity<long>
{
publicstring FirstName { get; set; }
publicstring LastName { get; set; }
publicstring Address { get; set; }
}
All the business entities should be part of the domain model and is defined in separate assembly. In this sample, I have created a class library (DataMapper.DomainObjects) to define the business entities.
Once the entities are ready, we can work on the base mapper for all entities. For convenience I have defined the data mappers and repositories in another class library (DataMapper.ResourceAccess)
The Base mapper defines an abstract method Construct that should be implemented by all the entity specific mappers for mapping the relational database fields to the object properties. The constructcommonData method populates the baseEntity properties.
Data access is a popular subject in most of the applications. There are plenty of options on various data access techniques and frameworks that often create confusion in the minds of developers choosing the right approach or strategy for creating an effective data access layer. Two main things that should be considered while creating a data access layer are simplicity and reliability.
When creating an application with a domain model, one should consider the usage of a layer that is used to map objects in the domain model to the relational table schema while keeping them independent of each other. The main objective of the data mapper is to strip the responsibility of persistence from the entity objects in favor of classes external to the entities. The repository uses this data mapper classes to access, modify and persist these entities back to the database. A repository is a layer that mediates between the business entities and data mappers in your data access code. The business layer uses this repository for all the data access functionality it requires.
In this article series we’ll see how to create a simple data access layer in C# that uses the data mapper and repository pattern implementation. The database used in the sample is SQL Server, which can be replaced by any other relational database. I have used the enterprise library data access application block for all ADO.NET queries.
Before writing the C# code, we’ll work on the database schema. We’ll use a customer table and the CRUD procs to demonstrate the repository and data mapper sample in this article series.
In the previous posts on NHibernate we have seen how to configure NHibernate and create a repository pattern implementation for accessing data using NHibernate. In this post we will see how to create different levels of mappings between our entities that participate in a customer-order application. For this we need to create two more entities (Product and Order) and define mappings between them.
The classes that are used in this sample are defined as
