This project is read-only.

Two-tier Rich Client Application Scenario

J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat.

Applies To

  • Windows Server 2003, 2008
  • Windows XP (client workstation)
  • Microsoft .NET Framework 3.5


In this scenario, you have full control over the creation and management of the database schema. The application being created is a rich client that will be deployed to employee workstations within an organization. Data for the application is located in an external database deployed within the organizations local area network (LAN). As a result, this scenario can be implemented using a two-tier design with presentation, business, and data access layers deployed to a client workstation and the database deployed to a database server.


Key Characteristics

  • Stand-alone rich client application that supports complex business rules.
  • Presentation, business, and data access logic are deployed to the client workstation.
  • The presentation layer uses an object based interface to interact with the business layer.
  • The application has full autonomy over the database schema.

Pattern Solution

The following diagram displays the major patterns used by this scenario and the layers where those patterns are implemented.


The following is a summary of the patterns used by this scenario:
  • User interface processing is handled by a front controller pattern.
  • The user interface is composed of multiple controls the user interacts with.
  • The presentation layer interacts with the business layer using factory objects to create and initialize domain model objects.
  • Objects in the business layer interact with the data access layer through repository objects.
  • Repository objects use components that are mapped to the database to perform operations against the database.

Pattern Description
Abstract Factory Define a common abstract interface for creating concrete objects during code execution.
Bound Data Control Control that can be bound to a data structure, which is used to provide data displayed by the control.
Composite View Combine individual views into a composite representation.
Data Mapper Implement a mapping layer between objects and the database structure that is used to move data from one structure to another while keeping them independent.
Domain Model A set of business objects modeled after a domain that represents the relationship between entities in the domain.
Front Controller Implementation of MVC where the controller is composed of a handler and abstract command objects. The handler accepts requests for multiple views and instantiates an appropriate concrete command object to process the request.
Page Controller Implementation of MVC with a one-to-one relationship between the view and controller.
Repository An in-memory representation of a data source that works with domain entities.

Pattern Solution Details

The pattern solution identifies primary patterns used by this scenario. The solution summary provides information on how the patterns are used within the design. Each table below represents a logical layer in the design and contains the patterns associated with that layer.

In this solution you will:
  • Use a Model-View-Controller (MVC) pattern to handle user interaction.
  • Implement a domain driven design using a Domain Model pattern.
  • Use an Abstract Factory pattern to create and initialize domain entities.
  • Interact with the database using Repository and Data Mapper patterns.
Client – Presentation Layer
The presentation layer is responsible for accepting user input and rendering the interface that is displayed to the user.

Pattern Info Example
Front Controller
User Interface processing is divided into three separate roles. The three roles are Model, View, and Controller. The Model represents data, the View represents the user interface, and the Controller is responsible for processing requests.
The controller is composed of two sub-patterns; handler and command. A handler is responsible for capturing user input, such as control events, and passing control to a command object. Command objects perform specific tasks and then passes control to a view, which uses a model to render the display.
Objects that contain data, the model in MVC, can be passive or active. When model objects are passive the view can only be updated by user interaction. An Observer pattern can be used to implement active model objects that notify the view and/or the controller when changes occur
Composite View
Page, and user interface controls are used to create a Composite View. Most development environments use controls and designers to create the user interface.
Controls are used to generate markup code that is rendered within the rich client. Controls used to define the user interface are responsible for generating markup code. For example, controls in the Visual Studio WPF designer generate XAML code, which is then rendered using the Microsoft .NET Framework 3.0.
Client – Business Layer
Business layer components implement the core functionality of the system, and encapsulate the relevant business logic. In this scenario a domain driven design is used to define business objects that represent a domain model. This scenario also describes the use of an abstract factory to create and retrieve business objects. However, the abstract factory pattern is not required when using loose layering guidelines where presentation components can skip the business layer and call directly into the data access layer. In this case command objects in the Front Controller pattern would interact directly with repository objects to create and get business objects.

Pattern Info Example
Abstract Factory (Optional)
An interface is defined that contains common operations to get and create objects. The interface represents an abstraction that is implemented by concrete factory objects. Consumers of the concrete factory objects only need to know about the interface definition.
Domain Model
Start by analyzing the business domain. In order to create an accurate domain model you need to observe entities within the domain and the interaction between those entities. This can be accomplished using object oriented analysis to create dynamic models and static class diagrams that represent the domain model.
Domain entities are responsible for implementing business rules. Entities from the domain model represent business objects that contain data and implement behavior. In other words, the business objects are responsible for implementing business operations and interacting with other business objects.
Client – Data Access Layer
Data layer components provide access to data that is hosted within the boundaries of the system, and data exposed by other back-end systems.

Pattern Info Example
A repository provides an in-memory representation of domain entities. As a general rule objects are normally not stored in memory with a web application or service. However, the repository hides all database interaction and provides operations that operation domain entities as if they were in memory.
Criteria objects can be used by the repository to generate database queries. In cases where you have multiple complex queries to retrieve an entity, a criteria object can be used to define selection criteria that is passed into a single get operation.
Data Mapper
Impedance mismatch between objects and relational data require mapping layer There are several factors that cause a mismatch between object and relational database structures. As a result, a mapping layer can be used to map object structures to database schemas. This allows developers to perform operations against the objects without having to know the database schema.

Technical Solution

The following diagram represents the technical solution by replacing patterns shown in the Pattern Solution with technologies, interfaces, or objects that are used to implement the patterns.


Technical Solution Details

The technical solution provides information about technologies used to implement patterns that were identified in the pattern solution. Each table below represents a logical layer within the design and provides information and examples related to implementing patterns in the solution. In addition to the technical solution for patterns, these tables also provide technical considerations that should be checked for this scenario.

In this solution you will:
  • Use objects to implement a Front Controller pattern (MVC).
  • Use Windows Presentation Foundation (WFP) to render the user interface.
  • Use a domain driven design approach to define business objects.
  • Define an interface for the abstract factory and create concrete instances that implement the interface.
  • Use the ADO.NET Entity Framework (EF) to define business entities and interact with the database.
  • Create repository objects that uses the EF data context to perform database operations against business entities.

When it comes to using a domain driven design approach the following concepts should be understood:
  • Aggregate Root – An aggregate represents a group of associated objects that are treated as a single unit for the purpose of data exchange. Each aggregate has a boundary and a root object that other objects outside of the aggregate can hold a reference to. In other words, the aggregate root has a public identity that other objects can access while other objects within the aggregate can only be accessed from within the context of the aggregate.
  • Bounded Context – When defining the domain model you also need to set the context for that model. There are many cases where multiple models are used within an organization or even within an application. The models may be completely different or they may represent variations of the same model. As a result, you need to establish the context in which a model applies, which is considered the bounded context.
Client – Presentation Layer
In this scenario Windows Presentation Foundation (WPF) is used to host the rich client application on a client workstation. User interaction is handled by implementing handlers and command objects as part of a front controller pattern. The command objects interact with factory and domain model objects to execute actions and initialize the model. Data from the model is accessed by WPF controls when the interface is rendered.

Check & More Info Example
MVC Objects
Objects are used in the presentation layer to implement a Front Controller pattern (MVC) The controller intercepts all inbound requests, interacts with the business layer to initialize a model (data), and chooses the appropriate view (page) to display.
A handler object and abstract command interface are defined to support the Front Controller pattern (MVC) Control events can be wired to a single handler, which then instantiates the appropriate command object, and interacts with the command object using the command interface.
Concrete command objects that implement the command interface are defined. Each command that can be executed in the interface is represented by a command object. Regardless of what action the user takes to invoke a command, such as a menu link or toolbar button, there would only be one command object associated with that command.
Windows Presentation Foundation (WPF)
WPF controls are used to define the user interface. The Microsoft Visual Studio WPF designer uses controls to create the user interface. Controls are available with Visual Studio and product companies are also developing WPF controls.
You are using Windows Forms controls when necessary. There are a large number of Windows Forms controls that provide functionality not available with WPF controls. If functionality required by your application is not supported by WPF controls you can use a container to host Windows Forms controls within a WPF application.
Client – Business Layer
This scenario uses a domain driven design to define objects that represent a business domain. These business objects contain data and implement behavior used to support business operations. In addition, the relationship between business objects is modeled after the business domain. Factory objects represent an initial interface into the business layer that presentation components use to create or get business objects. If you have a smaller application with loose layering guidelines where components in the presentation layer can directly call components in the data access layer the use of a factory is not required. Instead, you can directly access repository objects from controller objects in the presentation tier. Once the business objects are instantiated all operations

Check & More Info Example
Business Objects
You have an Entity Data Model (EDM) in the data access layer that is based on the domain model. You have used an object oriented analysis process to define dynamic models and class diagrams that represent entities in the domain that you plan to implement. The class diagrams are then used as a reference when creating an EDM in the ADO.NET Entity Framework. Entities in the EDM are defined as partial classes that can be extended in the business layer.
Define business objects that are based on data entities in the Entity Data Model (EDM). Data entities are partial classes that define properties and support interaction with the database. Partial classes defined in the business layer with the same name can be used to add behavior, which makes the combined class definition a business object when instantiated. Account.PNG
Factory Objects (optional)
Define an interface that provides common operations to create and get domain entities. FactoryInterface.PNG
Define concrete factory classes that implement the interface. AccountFactory.PNG
Client – Data Access Layer
The primary interface into the data access layer is through repository objects, which provide an illusion that business objects are being maintained in memory. For example, business and factory objects in the business layer can use repository objects to perform get, save, and update operations on business objects without having any knowledge of the underlying data store used to persist the objects. The ADO.NET Entity Framework is used to support Object/Relational mapping between the domain model and relational model in the database.

Check & More Info Example
Data Access Objects
Identify the aggregate roots in your domain model and define a separate repository object for each one. The aggregate root represents a top level object in a group of objects that are treated as a single unit when moving data across layers of the application. This group of objects is also known as an aggregate where only the root is accessible to objects outside of the aggregate.
Define operations that use Entity Framework data entities, or domain entities, as parameters and return values. AccountRepository.PNG
For objects that can be retrieved using multiple complex queries consider using a criteria object to define the queries instead of defining a separate operation for each query. A typical approach is to define a common criteria interface that all criteria objects implement. CriteriaInterface.PNG
ADO.NET Entity Framework
The ADO.NET Entity Framework is responsible for managing the database schema and providing a mapping layer between the database and data entities. In this scenario a database schema does not exist and we can take advantage of the schema generation and management functionality provided by the ADO.NET Entity Framework. This is accomplished by using the Entity Data Model (EDM) visual designer to create the EDM.
Use the domain model to create an Entity Data Model (EDM) using the ADO.NET Entity Framework visual designer. This will generate partial classes that represent data entities used to perform entity based data access operations. These data entities represent domain entities in the domain model and they will be extended in the business layer.
The Entity Data Model provides a mapping layer between the conceptual model and storage model. The Entity Data Model (EDM) is actually composed of three separate language types. The store schema definition language (SSDL) is used to define the storage, or database, schema. The conceptual storage definition language (CSDL) is used to define the entity types, complex types, associations, entity containers, entity sets, and association sets in the application domain. Finally, the mapping specification language (MSL) is used to describe the mapping between the conceptual model and target database.
Database Server
Check & More Info Example
Trusted sub-system is used to access the database. Define a common business identity and then use that identity when accessing the database.

Additional Resources

Last edited Jan 15, 2009 at 12:39 AM by prashantbansode, version 2


No comments yet.