Northwind N-Tier Blueprint is a Windows client application that can be used to manage the customers and their details of a fictitious company called Northwind Traders. This application is developed as a blueprint to showcase an enterprise standard architecture using the .NET 3.5 technologies like WPF, WCF, and LINQ to SQL. This can be used as a reference for building reliable applications with a service oriented and distributed architecture.
As this is a blueprint application, the functionality is limited to just what is required for demonstrating typical operation units in an application. When the application is launched, the main window opens with a set of buttons. Clicking on the ‘Load’ button will load all the customers from the database.
A new customer can be added by clicking on the ‘New’ button which opens up a pop-up window for adding the details of the customer. A selected customer can be edited by clicking the ‘Edit’ button, or can be deleted by clicking the ‘Delete’ button. The ‘Edit’ button opens up the pop-up window, loading the customer’s existing details. The ‘Close’ button shuts down the application.
This application follows an n-tier architecture pattern with different logical and physical layers, as shown in the diagram below:
Windows Presentation Foundation or WPF, which provides a unified programming model for building rich Windows smart client user experiences, is used for the Presentation Layer.
The user interface of this application is composed of windows and pages defined using XAML. All the user controls, images, styles, and other resources that make up the user interface will be part of this layer. The controls are bound to commands that are defined in a separate component. The command component will have proxy classes as service references pointing to the services exposed by the service layer.
Windows Communication Foundation or WCF is used as the communication interface between the presentation layer and the business logic layer. The service layer consists of service contract interfaces and a host that exposes the services.
The business logic layer is implemented as a set of assemblies (DLLs) in .NET 3.5. This layer would abstract the implementation of the business rules required for the business.
Business entity classes decorated with serialization attributes are used for transporting data across layers.
This layer provides functions that abstract the interaction with the database. Language Integrated Query or LINQ (specifically LINQ to SQL) is used in the data access layer for accessing data from the database. There is a DataHelper class which encapsulates the management of the LINQ to SQL data context. All the data access classes will pass the LINQ queries through the DataHelper class to the data context. LINQ entities are used to hold the data, and they are converted to business entities before passing to the upper layer.
Core services are independent of business functionalities, and exist to provide basic infrastructure support. It provides reusability, and support common functionalities like error handling, logging, transaction management, etc. The services of this component are used across all layers.
There will be only one central database for this application, which would reside on an SQL Server 2005 database server. The database will have just the tables to hold data, and no business logic would be implemented within the database objects.
All these layers are implemented as separate projects, as shown in the following image:
This application includes an exception handling and logging mechanism as explained below. A custom exception class (within Northwind.Common) is used for managing the exceptions of this application. Custom exceptions help us to standardize the manner in which the exceptions are handled, logged, and reported. All exceptions are trapped, and used as a starting point to create a custom exception. Additionally, the custom exception can contain any other useful information. The path the exception took through the call stack is caught using a custom call stack within the custom exception. This helps to avoid all the numerous traces given by the default exception class and to focus on only the required information.
There will be situations where messages need to be logged as information when an exception happens. This is useful when exceptions are not affecting the flow of the application, but we still want to know that something is going wrong. The mechanism implemented here also provides an option to log informational messages instead of throwing an exception.
All exceptions are propagated up to the UI layer, and a friendly message is displayed to the end user. There is also an option to display the error details including the stack trace. All exceptions are logged to an error table in the database from the service layer. If database access itself fails, the exceptions are logged to a log file in the application server. If file access also fails, they are logged into the event log of the application server.
| You must Sign In to use this message board. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
