If i follow MVC pattern, which place is the rightmost to instantiate the view classes ?
Is it inside
Main class
Model
View
Controller
I prefer instantiating the view classes inside a controller called InstantiateViewsCommand.
If your code adheres to SRP then you would see the instantiation of view as another responsibility. Which in turn would mean that it has no place in controller.
Instead it is a dependency of the controller.
Options 2 and 3 are obviously wrong, because point of MVC is to separate business logic from presentation and class should not instantiate themselves.
Which means that the views should be instantiate somewhere near where controllers are instantiated.
Though, I have no idea what "main class" is in your question. Sounds like some pointless artifact of language (as if using classes would automagically make it OOP).
Related
I am in the process of building a Cocoa app, which is comprised of a window divided in 3 sections. Each section is responsible for its own business and there are around 30 controls in it between table views, pop up buttons etc.
I started with a single Controller but things get messy pretty easily, so I decided to break the logic down in 3 controllers object (one each section of the view). I then created the NSObject reference on Interface Builder and hooked up all the outlets, actions, data sources and delegates. So far so good.
Now, the three sections pass objects to each other and therefore I need a way to set an object from one class to another. The object in question is a class variable, but as I have no reference to the object I don't know how to pass it around.
Is there a way to do this or is this just the wrong approach overall?
Solution:
As Sergio mentioned below in one of the comments, the solution seems to be to create a weak reference to the other controllers inside each controller as IBOutlet and then in the Xcode Interface Builder link the controller objects together. As a result, now each controller can access the exposed methods and variables of the referenced controllers.
Now, the three sections pass objects to each other and therefor I need a way to set an object from one class to another. The object in question is a class variable, but as I have no reference to the object I don't know how to pass it around.
What seems missing in your design is a Model (as in Model-View-Controller). This would be a class encapsulating all the state of your app, even if it is transitory state, so that each affected object have access to it.
One easy implementation for such a model class is a singleton, so that it is readily available in all of your controllers. Have a look here for some thought about the implementation of a singleton in Objective-C.
Once you have your model class, your controllers could access it like this, e.g.:
[MyModel sharedModel].myObject = ...;
This approach is good, IMO, if it makes sense for you to go in the direction of creating a Model for your design. This depends on the semantics of the object that your controllers share. So, there might be alternative solutions better fit for your case. E.g., one controller could be the owner of the shared object, and the other two could receive a reference to the first controller on init so that they can access its public properties.
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?
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.
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.
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.
I have a very simple question for MVC cause it is the first time i use it in my code.
I have 3 classes, the model, the view and the controller.
The question is :
Should I instantiate the classes separately and use them that way in my application or I can create a class that inherits this 3 classes and instantiate that class instead ?
Most importantly I don't want to violate the main MVC pattern.
You should instantiate the classes separately.
Moreover, it can pay to separate those classes into interfaces and implementation classes for later extensibility. For instance, if your model now reads date from file and later you need to be able to read the same kind of data from a database, you can then make a second implementation of your model class that implements the model interface. your controller that interacts with the model would then only need a change in how it instantiates its model. The rest of the controller implementation can remain the same (as it is has been written against the model interface).
Definitely three separate classes. The whole point of MVC is to have three classes that communicate (through the controller, which handles all the logic of the application). Creating a class that has all three in it would defeat the purpose of MVC.
In the more abstract way, inheritance should not be overused. With inheritance, you couple things together and make it harder to maintain. It contradicts with single resnponsibility principle (SRP) as well: "a class should have only one job".
Also, as any pattern, inheritance had better be only used it is neccessary and fits into the architecture correctly, for example: when there is a class Vehicle, classes Car, Bus and Truck should inherit Car: it is their nature.
So, in this current example, the answer is: It is correct to use model, controller and view classes separately, expecially when MVC pattern itself describes separating of these three parts :)
How does one build an application (Gtk/Winforms) with MVP pattern with nested presenters?
I cannot manage to get it right.
Lets say I have a main window (application shell) with a treeview (navigator presenter) and a panel (profile presenter), and want each of those 3 to be separate MVP-components?
public class ApplicationShellPresenter(IApplicationShellView shell);
public class NavigatorPresenter(INavigatorView navigator);
public class ProfilePresenter(IProfileView profile);
The first presenter is easy because I can create the main window in the composition root and inject in the constructor, but the other two, who creates them? The views are already created insde the main window. From what I can see I have two possibilities, the application shell creates them or I expose the views through ApplicationShellPresenter and create them somewhere else.
And to make things even more complicated, how do I use an IoC-container in all of this, to resolve presenters, views ?
Is my problem constructor injection? Should I introduce Init-methods instead to be able to create presenters without their corresponding views?
Any thoughts on this would be appreciated.
I solved it, the problem was actually having constructor injection.
I simply created a get/set property on my base presenter and I was good to go.
My application is following the MVC design pattern. The problem I keep running into is needing to call methods inside a Controller class from outside that Controller class (ex. A View class wants to call a Controller method, or a Manager class wants to call a Controller method). Is calling Controller methods in this way allowed in MVC? If it's allowed, what's the proper way to do it?
According to the version of MVC that I am following (there seems to be so many different versions out there), the View knows of the Model, and the Controller knows of the View. Doing it this way, I can't access the controller. Here's the best site I've found and the one describing the version of MVC I'm following: http://leepoint.net/notes-java/GUI/structure/40mvc.html. The Main Program code block really shows how this works.
Thanks for any answers.
Take a closer look at this paragraph from the article you linked to:
View
This View doesn't know about the Controller, except that it provides methods for registering a Controller's listeners. Other organizations are possible (eg, the Controller's listeners are non-private variables that can be referenced by the View, the View calls the Controller to get listeners, the View calls methods in the Controller to process actions, ...).
You have the observer pattern here between the View and the Controller. MVC is not a single pattern per se but at least two combined.
One way to get your head around managing the View/Controller communication is to use events. The View fires events on certain user actions (without knowing necessarily who might handle them.) The Controller processes these events and acts accordingly.