In the classic MVC:
The setup mechanism is the following:
Instantiate model
Instantiate view (Has reference to a controller, initially null)
Instantiate controller with references to both (Controller registers with view, so view now has a (non-null) reference to controller)
The question is why in the second step the view should have reference to the controller (i think the controller having a reference to the view is enough) ?
In the Extended MVC:
The setup mechanism is the following:
Instantiate model (Has reference to view, initially null)
Instantiate view with reference to model (View registers with model)
Instantiate controller with references to both (Controller registers with view)
The question is why in the the first step the model should have a reference to the view (what i know is that the model shouldn't know anything about the views, and the pattern Observer should be used in this case) ?
Here is the source link.
Thanks for advance.
The answer for both questions is the same. Your diagram is very abstract and you are totally right there should be no direct reference in both cases. You can either reference by a well defined interface(duck typing) or by subscribing to events happing at the observable object.
Look at your observer example. According to it, the only thing an observable knows about its observer is the fact that they respond to the notify method. So technically there is actually a circular reference between the two, but in case of the reference from the observable(model) to the observer(view), it's a week one.
Same applies for the first case. The View does not directly know the controller. But the controller has to be notified on UI events(e.g button clicked) and respond to them. This is often done by having the controller register to events happening in the view. But technically the view will maintain a list of its event responders. So there is actually a reference, but again a weak one. It will not stop you from reusing the same view with another controller.
So, your concerns are right, circular dependencies are a smell. But on the low technical level they are required and in order to achieve lose coupling you just have to make one side of them weak, which will make the dependency exchangeable
Related
Part of Apples description of the MVC-pattern is: ”The controller updates the model.” I interpret this to simply mean: The controller calls methods on the model, causing its internal state to change.
But for a controller object to call a method on a model object, it needs a reference to the model object. If multiple controllers need to update a model object, we need multiple references to the model object – one for each controller.
I don’t want my controllers to reach out in to global space locating other objects. I want higher level application objects to wire up lower level domain objects.
I’m coming from other plattforms where we use IOC containers for this stuff.
Looking for best practices as how model objects gets passed around in a cocoa application.
A concrete example: If I add CoreData to the cocoa application project template in xCode, the managedObjectContext is instantiated in the app delegate. How do I pass this instance to, for instance, a view controller or a nested view controller?
I’m using Swift.
concrete example: If I add CoreData to the cocoa application project template in xCode, the managedObjectContext is instantiated in the app delegate. How do I pass this instance to, for instance, a view controller or a nested view controller?
So personally I find this an anti-pattern: stuffing 'global' data in the app delegate.
But, that is what is very common on iOS and as you have noticed, what the standard Xcode template does. Unfortunately.
To make this a bit more workable, what I usually do is make the managedObjectContext private to the app delegate. Then when another object, mostly a UIViewController, needs to access this context, I explicitly pass it to the UIViewController when I instantiate it.
And when that view controller needs to display a new view controller, like for example some detail view, I again pass the context to it.
Then at least there a clearer form of responsibility. And it makes testing simpler because view controllers simply need to be configured (or injected in IoC terms) instead of grabbing hard coded global objects.
I know this not a full answer to what you were asking but I thought this bit was the most interesting of your question.
If I am using an instance of NSArray to populate a pop-up button, where in terms of MVC does that NSArray need to be initialised? I'm guessing it would fall under Model, however if that's the case, how do I initialise the array? Do I start a new implementation file to contain the array? (Obviously don't want to use my app delegate file as that would fall under Controller, not Model.)
The "model" part of MVC is the data that the app stores, presents, and/or allows the user to manipulate. It would largely be the same whether your app was running on a Mac, an iPhone or whatever. The "view" is the UI. That is the things the user actually sees on screen. The controller is the part that goes in between these two. It's responsible for implementing the specific behavioral logic for the app as well as "gluing" the view layer to the model layer.
So, with that said, the array of items to be displayed in a popup button may or may not be part of the model. It entirely depends on the specific UI you're implementing. If the selection is between a number of objects represented in the model, the array's contents would indeed be part of the model, but it still might be that the controller pulls the items out of the model in another form and turns them into an NSArray. It might also be a way to select between e.g. a fixed list of actions to be performed, in which case it's more properly part of the controller layer itself.
In other words, there's no one answer to your question. But, the likelihood is that the controller will at least provide the array in question to the UI, and may also be entirely responsible for its content. It all depends on exactly what you're trying to accomplish.
The initialization would happen within the model object, but that initialization would likely be called from a view controller (I wish these were just called controllers--there's no ModelController class.) Possibly in viewDidLoad but really wherever the best fit for your use case would require.
The model object should initialised by the controller object, usually in the viewDidLoad method. If a model object is owned by another model object (for example, if your custom model object has an NSArray instance variable, then your custom object is the parent and the NSArray is the child), then that child model object should be initialised in the initialised method of the parent model object.
I suppose your NSArray is a model object on its own, so it should be initialised in the viewDidLoad method of the controller object.
This is just one answer and not necessarily how everyone develop applications in objective C.
If I have an app with a small data model or with models scoped to their views, I will put the models on the AppDelegate or in the viewControllers themselves, if they are limited in scope to that view.
They will be initialized closest to where it makes sense in the app for that data.
Sometimes you will see a "FAT" viewController which represents a home screen controller or main screen controller and folks will pile the models on that class. Its very common.
But if I have an application with a large data model - lots of models that have lifetimes not scoped to the life of a view - then I will create a class in my application called *myAppNameHere*AppModel, and I will centralize the storage of application models, and use service classes as necessary to request data to populate/update models.
This is just one approach. And great question!
in the tutorials from http://www.vainolo.com/tutorials/ the position of the model is saved in the model. I want to save all data to file and want to get the same view, when I load the file.
Searching for an answer for this question, I got another more important question:
Is the GEF really a MVC framework?
GEF Controllers tells the mvc controller role is taken from the EditPart. It creates the specified objects.
Regarding the examples the controller holds view parts, but the mvc pattern tells, that the controller only reacts on user interaction and tells the view, it has to update or what ever.
Concluding on it the following code is wrong, because it is part of EditPart and it changes:
public void refreshVisuals(){
IPersonFigure figure = (IPersonFigure)getFigure();
Person model = (Person)getModel();
figure.setName(model.getName());
figure.setSurname(model.getSurname());
}
Regarding wikipedia the view has an observer on the model, so the following sentence from GEF is wrong, isn't it?
The EditPart syncs the actual model state to the view and implements the observer.
In the MVC pattern, the controllers must listen to the changes of the model. In GEF, EditParts are the controllers so they must listen to their model to update the view according to the new state of the model.
So what is correct?
To prevent cross-posting have a look on http://www.eclipse.org/forums/index.php/m/755178/.
The wikipedia states a the start of the article on MVC that " MVC comes in different flavors (MVC overview). Sometimes the view can read the model directly and update itself, sometimes this is done by the controller.
The primary concept that MVC provides is decoupling the presentation from the view, which should contain no logic. Changes to the model are executed by the controllers, and changes to the view are caused when the model is changed. But this does not mean that the controller can't be the one who updates the view when the model changes. Someone has to do it, right? I personally think that having the view directly read from the model is not a good practice since it makes them too dependent, and that model and view should be completely separated. This is great when you have to make changes in your model (for example a field is changed from being real to being calculated) - you don't have to change your view (but you may have to change your controller, but this is normally easier).
Hope this clears things up for you.
Using the MVC pattern in a desktop application, what's a good approach to introducing a view to its respective controller, and vice-versa? E.g., should you use constructor injection to give the view its controller, then have the view call a setView method on the controller and pass itself as the argument?
(Question isn't specific to any framework/platform.)
Views should be as dumb as possible. They shouldn't know about, or rely on having specific controllers instantiate them. At best they should have access to some kind of base controller class reference that is handed to them upon construction, usually as part of the "view data" object which wraps the Model to be used as well.
Your controller should be responsible for instantiating the view, giving the view the model it will be displaying, and returning the view's result. The view shouldn't be calling back into the controller to tell it what to return, as this gives control of the logical flow to the View, which isn't really MVC-like.
I have a object that is responsible for controlling screen navigation. A presenter can call one of two methods on this navigator object NavigateTo(string screenName) and NavigateTo(string screenName, object data). This latter method allows some context data to be passed to the navigator object.
Would it be the wrong approach when calling the NavigateTo(string screenName, object data) to pass the calling presenter as the data to the navigator and then allow the navigator object to use this to extract data from the view and/or model.
Some advice on this matter would be greatly appreciated.
Passing the Presenter to NavigateTo is a good choice. If you have multiple presenters you may want to write a interface that NavigateTo can use and have each presenter implement that interface. But if you just using one presenter for this or they already share some common interface then this is not needed.
One idea behind MVP is that you are change the view without effecting the underlying UI Logic. Passing the presenter doesn't effect this goal of MVP as you can change the view the Presenter is using. Now if you are allowing direct access to the raw view through the presenter (by exposing a view property) then that not good. What you want are methods on the presenter to expose the needed information to NavigateTo. That way when you chance the view you re implement the code behind those methods.