5

Should the view know the model:

enter image description here

or not:

enter image description here

?

The Student
  • 27,520
  • 68
  • 161
  • 264
  • Related: [Fat model / thin controller vs. Service layer](http://stackoverflow.com/q/8735466/11683), [Why put the business logic in the model? What happens when I have multiple types of storage?](http://programmers.stackexchange.com/q/176639/30872), [Where to put business logic in MVC design?](http://programmers.stackexchange.com/q/165444/30872). – GSerg Jan 15 '15 at 00:04

3 Answers3

2

Programmers often shortcut this and make the view specific to the model. For instance, if you're in a CRM app the model might have a firstName field; the view then assumes the model object it's given has a firstName field and shows that in the appropriate place.

This of course isn't reusable. If you are making a View to display a table of data, it shouldn't care which model field is shown in which column. It should just handle displaying and formatting tabular data in a generic way. But if your view is of a web page that's custom-built to the specific data it's showing, it can be okay.

So you have to decide on a case-by-case basis whether you want a view to know about the specific data it's showing or if you want it to be a reusable component.

In either way, any changes to the model's data should always happen through the controller. The controller is responsible for enforcing your business logic, and that's impossible when something else is circumventing it.

Richard Connamacher
  • 3,115
  • 19
  • 21
  • 1
    The model should contain the business logic and the controller enforces it --- this is an important distinction to make. The controller shouldn't know _why_ something happens, but it should know how to respond when stuff happens. Too often I see people embedding business logic in their controllers. – Greg Burghardt Jan 14 '15 at 19:58
1

No, the model and view communicate through the controller.

I mean, you can have them know each other, but that would induce tight coupling and would be hard to extend the functionality of the application.

Lawrence Aiello
  • 4,560
  • 5
  • 21
  • 35
  • 1
    How exactly would it "introduce tight coupling" in the view? Especially since your "solution" not only would cause the same type of "coupling" (whatever you mean by that word) for both model and view, but also would violate LoD. – tereško Jan 14 '15 at 19:37
0

By rights, Model, the underlying business entity, shouldn't be exposed directly to View. We normally use ViewModel, a presentation-specific model, which is derived from one or more Models.

Thurein
  • 2,536
  • 7
  • 34
  • 49
  • No. That's what you do in MVVM. The question is about MVC. "By rights", the original definition of MVC had the View aware of and communicating with the Model. – underscore_d Dec 11 '18 at 09:25