8

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

Funky
  • 12,890
  • 35
  • 106
  • 161
  • 1
    Funky look at my answer here: http://stackoverflow.com/a/7474357/559144 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... – Davide Piras Jan 05 '12 at 11:24
  • 5
    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). – MattDavey Jan 05 '12 at 11:53
  • @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! – Funky Jan 12 '12 at 09:40

4 Answers4

9

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.

MattDavey
  • 8,897
  • 3
  • 31
  • 54
Adam Houldsworth
  • 63,413
  • 11
  • 150
  • 187
5

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.

Wouter de Kort
  • 39,090
  • 12
  • 84
  • 103
  • For extra decoupling, you could add a service/application layer (http://martinfowler.com/eaaCatalog/serviceLayer.html) between the BLL and UI. – MattDavey Jan 05 '12 at 12:10
  • 1
    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:http://martinfowler.com/bliki/AnemicDomainModel.html (I have to admit, this happened to me a few times) – Wouter de Kort Jan 05 '12 at 12:34
  • +1 Agreed - the service layer should do nothing except **coordinate** the sequence of logic in the domain model. – MattDavey Jan 05 '12 at 16:06
1

look at my answer here: https://stackoverflow.com/a/7474357/559144  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... 

Community
  • 1
  • 1
Davide Piras
  • 43,984
  • 10
  • 98
  • 147
  • 1
    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 – Funky Jan 12 '12 at 10:13
  • @Davide,in case of MVVM,how to deal with INotified...in models –  May 05 '12 at 06:34
0

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,

Community
  • 1
  • 1
Dr. Andrew Burnett-Thompson
  • 20,980
  • 8
  • 88
  • 178