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

Question

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

Tamarin

Funky look at my answer here: https://mcmap.net/q/354764/-mvc3-and-entity-framework this is the usual way I do things and works well, not only for MVC and Entity Framework... in fact in MVC the model could be an entity type which only has some of the fields contained by the real business entities defined in lower layers, it depends if you really absolutely need all fields in the UI level as well or only some to do some data rendering and input... – Mitochondrion

FYI, "tier" and "layer" are not equivalent terms. Layer refers to logical separation as you described. Tier usually refers to physical hardware separation (ie database server, web server). – Titillate

@Davide Piras - Please put your post as an answer so I can mark it as the correct answer! Great stuff I gone with your method and its working nicely! – Tamarin

Answer 1

look at my answer here: https://mcmap.net/q/354764/-mvc3-and-entity-framework  this is the usual way I do things and works well, not only for MVC and Entity Framework... in fact in MVC the model could be an entity type which only has some of the fields contained by the real business entities defined in lower layers, it depends if you really absolutely need all fields in the UI level as well or only some to do some data rendering and input... 

Mitochondrion

Great answer! Very simple and clear cut! I have implemented this into my solution and it is working nicely everything is divided up accordingly making it easy to add to in the future as opposed to having to duplicate model objects – Tamarin

@Davide,in case of MVVM,how to deal with INotified...in models – Spatola

Answer 2

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.

Rolling

Answer 3

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.

Axis

For extra decoupling, you could add a service/application layer (martinfowler.com/eaaCatalog/serviceLayer.html) between the BLL and UI. – Titillate

A service layer could be beneficial, for example if you're using WCF or something, but you need to watch out that the logic that should be in your Domain Model, doesn't leak into your service layer and you end up with an Anemic Domain Model:martinfowler.com/bliki/AnemicDomainModel.html (I have to admit, this happened to me a few times) – Axis

+1 Agreed - the service layer should do nothing except coordinate the sequence of logic in the domain model. – Titillate

Answer 4

As a related topic, please see this related answer which I posted recently on avoiding duplication of code and correct architecture in a cross-platform client/server system.

I have +1'd the other posters in this thread as this is not intended to be a full answer, just useful information related to the question.

Best regards,

Unpeople