Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

.NET N-Tier Architecture: What do I do about the Model objects?

I am creating a solution from scratch, using ASP.NET Web forms C#.

I am concerned about the model objects as I don't want to create duplicate sets of model objects in each layer. What is the best practice for using Model objects in 3 layer architecture in Web Forms?

The structure I have in mind is as follows:

  • UI
  • BLL
  • DAL
  • Model

The Model will contain all the model classes that can be used in each section of the layers. I thought this would be useful as each layer needs access to the model objects. For example:

  1. UI calls a method in BLL passing in a model object filled with data.
  2. BLL calls a method in DAL passing through the object which is saved in the database etc.

Thanks

like image 269
Funky Avatar asked Jan 05 '12 11:01

Funky


People also ask

What are the disadvantages associated with an N tiered architecture?

The Disadvantages of the N-Tier DeploymentMore cost for hardware, network, maintenance and deployment because more hardware and better network bandwidth are needed.

What tasks are carried out by the application layer of an N-tier architecture?

N-tier application architecture provides a model by which developers can create flexible and reusable applications. By segregating an application into tiers, developers acquire the option of modifying or adding a specific tier, instead of reworking the entire application.

What are the three main advantages claimed for an N-tier architecture?

What are the Benefits of N-Tier Architecture? There are several benefits to using n-tier architecture for your software. These are scalability, ease of management, flexibility, and security.


2 Answers

Models can be a cross-cutting concern with your layers, which is a quick way to do it. Or you can create interfaces for your models such that you could simply flesh out the interface in something like the BLL - this at least stops it being cross-cutting.

It further depends on if your models are simple data containers (anemic domain model), or contain behaviour, such as the ability to validate themselves or track changes themselves (rich domain model).

You can find that your DAL actually consists of two parts: the boilerplate-never-specific to an app code to talk to the database, and the app-specific populate-the-model code. We have this situation. We share interfaces of our models around, the app-specific DAL code can use this interface in order to push and pull data from the model, but the "true" DAL code works with raw stuff.

like image 103
Adam Houldsworth Avatar answered Oct 23 '22 01:10

Adam Houldsworth


In a relatively small application, you can share your Domain Entities all the way up to your Presentation layer but be aware of the coupling this introduces.

If in your Databinding you except an Entity of type Customer with a property Address with a StreetLine1 and StreetLine2 property then all your layers are tightly coupled together and a change in one layer will probably cause changes in other layers.

So your decision should be based on the scale of your project and the amount of coupling you can have.

If you go for a low coupled design then your BLL will use your DAL to retrieve entities and use those entities to execute behavior. The BLL will then use Data Transfer Objects to pass to your Presentation layer so there is no coupling between your presentation layer and your Domain Model.

like image 31
Wouter de Kort Avatar answered Oct 23 '22 00:10

Wouter de Kort