3

According to this answer, it seems to be ok to call model from the view.

Can I call a Model from a View?

Now my question is, how would the wiring look like?

Would the controller pass a Model Factory to the view? (Which I think would defeat the purpose of this question, since it would have to bypass the controller in order to do that unless I'm understanding wrong)

Or

Would the View have a model factory injected in View's constructor before the view gets passed to the controller?

Community
  • 1
  • 1
Tek
  • 2,888
  • 5
  • 45
  • 73
  • This *may depend* on your framework – Jürgen Paul Apr 14 '12 at 04:19
  • Depending on the level of abstraction VS. performance you are looking for you might look into using a Dependency Injection framework that is capable of setting data in the views when they are created based on a model to view mapping. (See: http://en.wikipedia.org/wiki/Dependency_injection) Also, what MVC are you actually using? – Resist Design Apr 14 '12 at 04:19
  • @ResistDesign I was just studying about the MVC framework, I haven't really seen much code so I wondered what it looked like. – Tek Apr 14 '12 at 04:24
  • @ResistDesign Also, wouldn't a model factory be enough instead of a dependency injector? I'd just need the model, nothing else. – Tek Apr 14 '12 at 04:32
  • It really depends on how you want to decouple your code. This is bit difficult to discuss in the abstract, you should create a test application. That will really help you gain insight into the logic behind all of this. – Resist Design Apr 14 '12 at 04:58
  • It would look messy. I've worked with code that was written this way and it's very easy to get lost. – GordonM Apr 14 '12 at 06:47

1 Answers1

2

At first glance, I don't see a problem with that. Let's walk through the alternatives:

  1. Passing the raw model into the view, type hinting off generic model interface

    On the surface, this may seem ok. However, if your models aren't consistent in their apis (such as $model->getPerson($id), which is fairly likely), this is effectively tightly coupling the controller model and view together.

    Since your view can't really accept any model, injecting the raw model from the controller may be a bit too liberal and open the door to inconsistencies or weird errors down the road.

  2. Passing the raw model into the view, type hinting off the desired model class

    This solves the liberalness problem from the prior solution, in that only the correct model can be passed. But now you've further coupled the view to that model. So that's not good.

  3. Instantiating the model inside the view.

    This is also not an ideal solution, since now you can't mock out your model for testing and have completely coupled the view to the model. A definite SOLID violation.

So that basically leaves injecting the model's factory. It allows the view to determine which model it needs (and hence asks for from the factory). It allows the model to be mocked out (by swapping a different factory). And it also allows for arbitrary models to be passed, by adjusting what the factory returns.

So the dependency is now loosely coupled, and you're instead dependent upon a factory (which is a better dependency to have).

That's my first thought. I'd need to think about it further to see if there's a cleaner solution, but there you have it...

PeeHaa
  • 71,436
  • 58
  • 190
  • 262
ircmaxell
  • 163,128
  • 34
  • 264
  • 314