Nearly two years a go I probed Internet to find out a good reference architecture for my ASP.NET applications. What I meant GOOD ARCHITECTURE was an architecture that:
- IS FAIRLY SIMPLE
- IS BASED ON N-TIED ARCHITECTURE
- IS PRODUCTIVE
- IS EASY TO IMPLEMENT
- DOES NOT NEED A NY 3rd PARTY CLASSES (I.E. NHIBERNATE)
- CAN BE USED FOR A WIDE RANGE OF DATABASE SERVERS
- IS WELL-DESIGNED AND DOES NOT CONTRADICT WITH OOD DICIPLINES
I tried out a variety of architectures I’d come across but I found them somehow faulty. For example, in some cases, typed datasets (datatable) was used with TableAdapters attached to them! This contradicts the rules of a N-Tier application because an Entity would carry out it’s CRUD functions, that must be placed in DAL layer, with itself anywhere (i.e. BIZ layer).
I finally designed a shining architecture (!) that is going to be shared and discussed here. Since a weblog is too small for discussing about all details, I will write about the main parts of the implementation and about main ideas. Therefore we may forget about the details and set our mind to the significant things. I invite you to leave comments and let’s grow this architecture and rectify it’s problems.
The implementation that I am going to discuss is simple and is based on a (somehow) standard 3-tier architecture. In this architecture, four layers play a part:
- Common Layer : includes entities and is common between other three layers
- Data Access Layer (DAL): includes CRUD operations
- Business Layer (BIZ) : does business operations, check business rules, manage concurrencies,…
- Presentation Layer (UI)
The presentation layer can be either Web-based or Windows-based. However, since my focus on this article is on the implementation, I will stick to a Web UI.
As the above image shows, each layer is dependent on the common layer and the underneath layer. For example, Biz layer can access the common and DAL layer but can not access UI layer. A layer is not necessarily a physical component. In the other hand, you may define a class for each layer and put all of them inside a single application (i.e. EXE). However, in order to reduce the coupling and increasing the cohesion, we will create a .DLL for each layer and separate them psychically.
The Common Layer
As mentioned before, the Common layer comprises all Entity definitions. An Entity definition is a class describing an entity. An entity is an object that will transmit information between layers and is, nearly, a representation of actual data in DB. Entities can be of any type, however, I strongly recommend to use Typed DataSets (DataTables) because you can work with them visually and ASP.NET UI components are astonishingly match with them.
In order to create the Common layer, first start a solution and name it ThreeTierArch. Afterwards, add a Class Library project to the solution and call it CommonLayer. This will, by default, produce an assembly named CommonLayer.dll and a namespace called CommonLayer. In Solution Explorer window, right-click the CommonLayer project, choose “Add new item” and add a DataSet to the project. An empty DataSet is added and you may drag a DataTable from Toolbox window inside it. DataSet designer let’s you design your DataSet visually and create any relationship needed between tables.
The above image displays a sample DataSet with two DataTables having a Master/Detail relationship.
That’s it. Add as many as needed data tables and datasets to your project. These are our Entities. Something that I usually do, to shorten my entity names, is to inherit a class from their class. For example, I might add a class like the following one to CommonLayer in order to shorten my entity name:
public class PersonEntity : PersonDataSet.PersonEntityDataTable
Needless to say that this is not necessary and it is just to get rid of long names!
Ok, it is enough for the common layer. Tomorrow, I will talk about the DAL layer and we will see how to implement it.