As we move into the third part of our series, we will talk a little about what architecture are we catering to. As mentioned in the series title, we would like to design an N-tier service oriented application. Lets see what that means first: 

  • N-tier – this part should be simple for any developer to understand. The application will comprise of multiple (N) loosely coupled layers, potentially dividing up the data storage/retrieval, business-entity flow and the client/view activities. This is an extension of the traditional 3-tier or 2-tier (client-server) models
  • Service-Oriented – this is the section of the various layers, which should allow us to build a pure multi-tier experience. Most N-tier implementations comprise of code separation between business logic, database and client (web) interfaces. This leads to a separation on the database server, and the application/web server. Our model (though not original) will provide a separation of database, client (web/mobile) and application logic, thus allowing different physician/virtual servers to separate the 3 activities. We achieve this by inserting a “Service” layer on top of the business logic code

Here is a high level (simplistic) diagram of what our architecture will look like:


The big question that instantly comes to mind is how sound is this architecture. The answer to that would depend more on your particular application. This is by no means the end all architecture for all applications.

Adding a service layer on every application is not the right way to go. But if you are building an application which maybe potentially be accessed, wholly or partially, through multiple interfaces (not counting a responsive website), then adding a service layer early on helps a lot. Another consideration would be the amount of data processing you expect, or the number of simultaneous users that would access the application. Keeping the client layer (mobile/web) light and moving out the business layer to a separate server (or multiple servers) might be something that could help you application in the future.

Lets talk about the various layers:

  • ORM – this would a standard Object Relation Mapping layer like NHibernate or Entity Framework in our example’s case 
  • Models – this would contain the database mapped POCO/POJOs from the ORM along with any flat models that might be needed specifically for the application
  • Utils – this layer would contain classes that might be used to help other layer classes
  • Business Logic – this would be where the bulk of the application logic would reside. Our assumption in our example is that the database would not contain major stored procedures. The application core will remain in the business classes. There might be a need to break the Business Logic layer into multiple smaller library projects
  • Service API – this is the layer that provides the default separation between the clients (web/mobile) and the business logic. In our example this would be represented by an ASP.NET Web API project
  • Client projects (Web/Mobile) – no explanation need here. The web code in our example will be an MVC application

I hope my description of the logical architecture was clear enough for you. If not, feel free to post your questions in the reply area. Until next time…have fun!