0

Edit: Thank you for the answers. They are helpful. My last question is, is it possible to do this via REST?

To start, I realize these have already been somewhat answered in the following two links, so please do not close this as a duplicate. I am legitimately confused!

MVC vs. 3-tier architecture?

MVC Vs n-tier architecture

From what I understand, the MVC design is for the "presentation" tier in the 3-tier architecture to allow for GUI creation. I get that. However, where I am confused is how the data model in the GUI is supposed to interact with the "Tier 2" application logic. This is how I am envisioning it:

enter image description here

So from what I gather, whenever a user interacts with the GUI, and the Model is updated, is it the model's responsibility to then talk to the rest of the architecture via a web server API?

Community
  • 1
  • 1
Lawrence Aiello
  • 4,560
  • 5
  • 21
  • 35

3 Answers3

1

Depends on how you wanna structure your project.

For example: Sometimes we don't want to expose our model classes (entities). So, we create DTO classes to receive information from UI, that will be handle by controllers and pass them to business logic that translate them to entities. It's used a lot in SOA solutions, where we can expose ours services.

Example: UI request -> Controllers with DTO -> BLL (translate to real model classes) -> Repository/DAO -> DB.

Icaro Camelo
  • 382
  • 1
  • 10
1

Discussion of tiers is really orthogonal to discussion of MVC.

MVC doesn't really talk about how the model is supposed to talk to outside services/data layers. There are some good discussions here about it. There is debate as to whether data access/persistence should be in your model layer, or your controller layer. I much prefer it in my model layer.

I also prefer the Anemic Domain Model, so I tend to put the actual talking to the DAO layer in the service part of the model, not the domain objects. But putting it into the model objects works well too, you just want to separate your persistence layer from your business logic layer with the DAO pattern.

The point is though, both your tiers need their own Model, and their own DAO layers. The DAO layer of the Presentation Tier will talk to the Business Tier. The DAO layer of the Business Tier will talk to your Database/Storage Tiers.

This isolates each tier from changes in the other tiers.

Community
  • 1
  • 1
Rob Conklin
  • 8,806
  • 1
  • 19
  • 23
1

Your controller contains the lightweight application logic, which is needed to coordinate work between model and view. For example, your controller has the responsibility to get the data from a service/data source, and map the resulting model into a view model that is given to your view.

Views should also contain as little logic as possible. As the view model is created specifically for a view, the only responsibility of the view is to render itself using the view model's data.

The model you are referring to is indeed the result of what you get back from the back-end. It could be proxy entities returned by a WCF service, data entities returned by a web API or entity framework objects if you access the database directly (all depends on what architecture you want to use). This model is then used to construct a view model, which your view uses to render itself.

L-Four
  • 13,345
  • 9
  • 65
  • 109