0

I find myself needing to have a View expose its Model and Controller references. Is this the smell of bad design? Or is this considered "safe" practice?

For example: I have a list (composed of a ListView, ListController, and ListModel) and many list items (composed of a ItemView, ItemController, and ItemModel).

When I create the ItemModel, ItemView, and ItemController for each list item, I pass the ItemView instance off to the ListView. But, at some later point, my ListController needs a reference to the corresponding ItemController instance.

So, would it be more proper to pass both the ItemView and the ItemController in to ListView::addItem(), or just pass in ItemView and expose an instance method such as ItemView::getController()?

Or doesn't it matter? Is each approach equally viable? If followed to their logical conclusion, does either tactic result in an anti-pattern?

Chris Tonkinson
  • 13,823
  • 14
  • 58
  • 90
  • `But, at some later point, my ListController needs a reference to the corresponding ItemController instance` -- Why? If you're decoupling your classes properly, you shouldn't need this. – Robert Harvey Mar 05 '12 at 19:24
  • `When I create the ItemModel, ItemView, and ItemController` - you create a controller for each item in the list? - that is a smell for me. – Jakub Konecki Mar 05 '12 at 19:33
  • Are you talking about web or desktop applications ? There is a difference. – tereško Mar 05 '12 at 19:48
  • @RobertHarvey: Good question. Perhaps I need to reconsider my delegation paradigm. – Chris Tonkinson Mar 05 '12 at 19:48
  • @JakubKonecki: I'm currently **attempting** it that way, yes. Would you suggest then that `ListController` shoulder the entire burden? – Chris Tonkinson Mar 05 '12 at 19:51
  • @tereško: It's a Flash application (AS3). – Chris Tonkinson Mar 05 '12 at 19:52
  • @RobertHarvey: Phrase that as an answer, and I'll accept. Your challenge caused me to re-evaluate exactly how the components were interacting, and I wound up restructuring in such a way that, as you correctly suspected, exposing one controller to another was proven unnecessary. – Chris Tonkinson Mar 07 '12 at 15:38

3 Answers3

1

In the mvc pattern the users request shall be routed to a controller, say invoicecontroller, that has actions. Lets say the default action, Index, returns a list of invoices; the controller then creates a model with a list of invoice objects, instantiates the correct view and injects the model into the view. Now it is the views turn to do its magic. It renders the best view it can with the data it has, which may include routes to one or more controllers. In NO instance should the view (or model) do business logic themselves. That said, I totally agree with Jakub. Hope that helps.

Mattias Åslund
  • 3,877
  • 2
  • 18
  • 17
1

But, at some later point, my ListController needs a reference to the corresponding ItemController instance

Why? If you're decoupling your classes properly, you shouldn't need this.

Controllers almost always address a functional domain. An example of such a domain might be "Sales" or "Admin." In addition, MVC also supports the use of "Areas," which provides an additional hierarchical level of organization.

Adding references to controllers from other controllers is at cross-purposes with this organizational structure. If you need to combine functionality to make your code more DRY, ordinary refactoring will accomplish that. You can also inherit controllers from a base class containing common functionality.

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
0

Considering you are not actually showing any code at all. In my opinion, you should change your design. A controller is not supposed to communicate with another controller (directly), MVC dictates it: reference.

If you need to invoke a controller action from another controller, consider using delegates or composition. Instead of directly invoking the controller action.

Community
  • 1
  • 1
Marcel Valdez Orozco
  • 2,985
  • 1
  • 25
  • 24