10264 and web architecture basics

When teaching 10264, a lot of web architecture questions arise about the differences between how to structure an application when using web forms or MVC. My intention of this post is to answer some of these questions.

Let's start out with some basics, a classical three-layered approach, where each layer has different responsibilities:
User interface:
display data/information and handle all interaction with user
Business service:
Business logic - responsible for enforcing business rules and provide methods used by user interface. A business rule for an B2B e-commerce site could be that if there are outstanding payments for a certain customers, that customer cannot place new orders. Or when registering a new user, a valid email adress must be entered so that we can send order confirmations later.
Data Access Layer:
Does CRUD (Create, Retrieve, Update, Delete) operations to the database (or perhaps several databases, web services, file system) to store or retrieve data.  Can also do some Object/Relational mapping.

Besides these three layers, a domain model is designed for all objects that are important in the application domain containing their properties and relationships. This could be the Order class, Customer class etc.
These domain classes are used by all layers, for instance if the UI wants to get all orders for a customer, the UI code creates an instance of the BSCustomer class, calls a method BSCustomer.GetAllOrders(customerId). The BSCustomer class creates an instance of the DALCustomer class, calls a method DALCustomer.GetAllOrders(customerId) and calls the database somehow (by stored procedure, T-SQL string, or OR-mapping framework) and returns a list of Order domain objects, which the UI shows to the user.

Figure: Three layered architecture and some code. Not included in this picture: settings passed to layers (conn strings etc), security checks, error handling and other *details*...

At it's simplest, a BS method just calls a DAL method directly, but it often contains validation (is this user allowed to do this, are all parameters OK, etc) or calls several DAL classes and methods. So the BS layer provides an abstraction for the DAL layer, that contains more details. BS contains methods (and support methods) for doing things that provide actual business value to the application  (driven by the UI, such as PlaceOrder) and hides the actual DAL details, making it easy for all that use the BS layer.

By doing this, we have a clear separation of concerns between our layers. The DAL can be rebuilt to use another database, or OR-mapping tool and as long as the interface used by BS does not change and each layer can be developed, refactored and tested separately. By using custom domain objects, the UI does not have to know details about the database (for instance, if the order status is stored using a string, number, relations to other table, etc).

The need for BS methods and domain objects is driven by the needs of the consumers - the UI, and if many applications use the same BS layer, all needs have to be considered.

How about using more layers?
There is no upper limit to the numbers of layers that can be used. We could build a three layered app for a mobile device, which then calls a web service, that has it's own layers. That's 6. Don't do this just for fun. Start easy. Put classes in different folders to start with. Put them into separate visual studio projects when there is an actual need to separate the assemblies, for instance if they will be used by other applications.

Do you write unit tests?
Instead of having hard coded dependencies between layers (UI must know how to create a BSCustomer class with certain methods), we can create an interface (like IBSCustomer) that the UI uses. This way we can change the BS-layer to any other implementation as long as if implements the same interface. By using a Factory pattern (link), we can let some other component be responsible for creating our BSCustomer class. Dependency Injection could also to the same. Hence, we get classes more loosely coupled to each other and according to the SOLID principles, a better object oriented design, which will be easy to write tests for.

Done with the basics!

How does this map to ASP.NET web forms?
A typical approach would be to let the code behind use the business layer to retrieve data, which is bound to to asp.net server controls. The communication with business layer is done by using our domain model. If UI developers like to use datasources and UI wizards, set up BS classes and methods to use a ObjectDataSource.

ASP.NET MVC uses a model to handle database access, will this ruin our 3-layered approach?
The MVC approach is in the ASP.NET context, a way to build the UI layer in a structured and testable manner. It does not interfere with other parts of the architecture.

Yes, it is possible to use an OR-mapping tool to build a domain model as well and also handle all database actions, but it does not have to be done like this. The Model in ASP.NET MVC is practically a View-model - a model used to serve data to the view, and to simplify development of views for the front end coder.  Often two different models are used - one domain model used by all layers, and one model used by the UI. They might be very similar, but do not have to be, since they have different responsibilities. Another approach is using several UI models, one for displaying data and one for fetching data. Keep in mind, MVC is primarily used to structure the UI.

What if Entity framework is used, how will this affect the architecture?
In most examples and quick demos during the course, Entity framework is used. In these examples, EF defines the Domain model (same as the MVC Model in these examples), the DAL and to simplify MVC examples, the business layer is not included. Still, keep the overall picture above in mind!  With code first in EF (nice features in 4.1), this will be clearer. You create your own domain model, and define a data context class to use them in EF. Scott Guthrie has written a post about this: http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx

Use the course as a way to share your experiences and ideas regarding architecture with your course mates. Real life examples (and problems) are fun!
Does your business slow down during the summer? Use this opportunity to take a course :-)