So we have an app using MVVM architecture and we call view models like XViewModel (eg DatasetViewModel), views XViewController (eg DatasetViewController).
However we don’t know what to name the protocol the XViewModelImplements.
Related
I have just read this article about MVVMC pattern. Now I have a question. Should Controller be injected to ViewModel, or ViewModel should be injected into Controller?
The MVVMC is simply a MVC where the View is replaced by a ViewModel pair.
The View interacts ONLY with the ViewModel taking advantage of the powerful data binding mechanisms in XAML based technologies.
The ViewModel can notify the Controller but SHOULD NEVER inject a controller.
I have put together a simply sample based on the well know sample of Josh Smith on MSDN... where I have introduced a Controller.
It depends on what you are doing. I'm going to guess that most of the time the Controller would not need to be injected into either, but if it is needed, it is more likely to be needed in the ViewModel. Let me explain.
What are you doing with the controller? You must be doing something.. If that "something" is solely related to "what the data looks like", then it belongs in the View. If it is related to "what is be being shown to the user" then it belongs in the ViewModel.
I'm injecting a controller into one of my ViewModels. My ViewModel represents data which is then graphed in the View. I have a command which moves a data item from the current graph to a new graph. Since this changes "what is being displayed in the graph window" I implemented the command in my ViewModel. The ViewModel removes the data item from its own collection of items, and then uses the Controller to request a new view be created for that new data (it already had this functionality).
Looking at the article, I don't see arrows between the controller and the view
The ViewModel is a contract between the View and the Controller, and ideally does not need to know about (be dependent on) either.
So I definitely wouldn't be injecting a Controller into a ViewModel.
I'm not sure I'd be doing the opposite either: the controller is normally responsible for creating new ViewModel instances. If you want to go for a more loosely coupled implementation, you could go for injecting an abstract factory into the Controller, to avoid directly creating new instances of your ViewModel classes.
I believe the Controller should be injected as an abstraction IController. The ViewModel needs IController to be able to navigate to a different View/ViewModel.
For example, in ViewModel:
IController _controller;
public MyViewModel(IController controller){
_controller = controller;
}
void NavigateHome();
{
_controller.NavigateHome();
}
The abstraction IController is better than injecting the Controller itself for these reasons:
Testability. You can inject a mock IController and test the ViewModel
Decoupling. ViewModel doesn't have to know Controller.
I developed a lightweight framework for doing MVVMC in WPF.
It has a lot of resemblance to MVC in Asp.NET Core.
Check it out if you're looking for a WPF solution.
Blog post with documentation:
http://michaelscodingspot.com/2017/02/15/wpf-page-navigation-like-mvc-part-2-mvvmc-framework/
GitHub:
https://github.com/michaelscodingspot/WPF_MVVMC
I don't understand : in all tutorials on iOS, it shows a classical 3 parts Model, View, Controller, then why does XCode prefix controller with xxxViewController instead of xxxController ?
This makes believe that the controller is just for the View and not for the Model and so close to MVVM than classic MVC.
In answers given it says it's not MVC.
But if I look at standford University course it clearly depicts iOS development as classical MVC in Lecture1.pdf # http://www.stanford.edu/class/cs193p/cgi-bin/drupal/downloads-2010-fall
Xcode doesn't do this for all controllers, Just for view controllers (which are subclasses of UIViewController). It makes it easier to find which ones manage views, You can create other controllers and name them what you like.
As g_wolfman comments in this Apple discussion thread:
Despite Apple's use of the term MVC in their developer documentation,
they don't actually use it; they use a variant of
[Presentation-Abstraction-Control
(PAC)|http://en.wikipedia.org/wiki/Presentation-abstraction-control].
The key difference is that in MVC, the view gets information directly
from the model and the controller is only concerned with changing the
model. Hence the view may need to know how to transform data from the
model as part of creating the view. In PAC, the view and the model are
completely isolated from each other; everything passes through the
controller. This allows the view to be written in such a way as to
avoid needing any "business logic".
EDIT - --
from apple doc - http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html#//apple_ref/doc/uid/TP40002974-CH6-SW1
Combining Roles
One can merge the MVC roles played by an object, making an object, for
example, fulfill both the controller and view roles—in which case, it
would be called a view controller. In the same way, you can also have
model-controller objects. For some applications, combining roles like
this is an acceptable design.
I'm new to programming, iphone application programming in specific. After reading a bunch about MVC I decided to give it a try in a small application. As to my understanding, MVC works like this:
Model: data, manipulating data, retrieving data.
ViewController: formats data from the model (NSDate to specific style), etc.
View: the actual gui.
If this is indeed a correct formulation of basic MVC theory, my confusion lies in how data is passed between the model, VC, and view. Example: if I make calls to twitter and get the data in the model, how do I (correctly) pass this information to the VC for further work. I know that between the VC and View one mostly uses IBOutlets. The Model is my real problem.
In my last app I made an NSString variable in the app delegate so I could access that data from any class. However, I read that this is not the best approach when the app becomes complex because the delegate is in charge of starting, ending the app, not holding data.
I've read of delegation methods, singleton's, NSNotification (which I've used to call methods in other classes). The problem is that I don't really understand how to use these techniques to pass data from the model to other views.
Please let me know if my question is unclear.
If you think about reusability, the main components that can be reused again are your model objects and view objects. They can be moved to different apps and still used properly. Your view controller is what is really specific to your app and where most of the app logic lies.
So in your example, you could have a twitter object that stores information and tweets from a user perhaps. You would create that class with all its functions separately within its own .h and .m file. Then in your view controller, instantiate the twitter class with data that is retrieved and begin using it from within the view controller.
Your view controller is actually retrieving the data but your model object is the one maintaining the data. In this way, you can pass on the model data with your twitter object to other view controllers.
Control over the application resides in the controller, so it is the object that will retrieve or save persisted data, update views with that data, and handle various events. Consider it the glue between the model and the view!
For example, if you were to click on a button to open a new modal view, you'd handle that event in your view controller. In the method that responds to the clicked button, you will create or access the new view controller and present it using presentModalViewController:animated:. If that new view and controller needs data that your current controller has access to, you could set a property in the new controller to refer to the object.
I am developing a special type of view controller for an iPhone component library.
I have got the who view controller working well, but I need to change it so that it works in one of two ways:
Either it is an abstract class which you must subclass and provider the implementation for a specific method which the controller will call whenever it needs its data.
Or it needs to be a useable class which has a property which is a selector... when you set the selector it specifies the method which should be called to collect the data.
I would like to know how I can implement either of these and which you would recommend
The standard way of doing this in Objective-C and the iPhone is through delegation.
Normally you provide a property in your view controller called delegate that is typed for a particular protocol you create. Then who ever is using your view controller will set the delegate property with their delegate for your view controller. You can then call the methods in your protocol on their delegate.
See the answer at this SO question for a full example.
Also read the Cocoa Fundamentals Guide for information on what delegates are and why they are used in Cocoa. There is also an example there of how to create delegates for your own custom classes.
I have been wondering for a while, after asking different people and without any of them providing what I would call an "at least a bit concrete answer":
Question:
Where, in an iPhone application should an application keep the references to it's Model Classes (using the MVC approach) ?
In iPhone (and Cocoa) applications we have what we call the "App Delegate", which basically start's up our application and inits our controllers, also handles UITouch events.
So is the App Delegate a controller ? a model class ? none of the two ? I think not knowing that also makes confusing to know where to put the Model References.
Example:
You have the Application Delegate, that delegate contains a reference to your Application's View Controller. If my Application would use Model Class A ( which is a webserver daemon class ), and a Class B which stores data queried by that webserver.
Where would you guys store the references to A and B ? (App Delegate ? View Controller ? Both ? )
There are many options here, but as an example, I would really like to know how would you guys use mvc to put together this application which only uses one View.
It is tempting to put everything in the AppDelegate, but if you start doing this, then your AppDelegate will be full of reference hacks. If you are doing a strict MVC, then you should have 3 things:
A Model
A View Controller (Only for view logic)
A Controller (For coordinating between the view and the model)
So for example, I have a model Foo and a Foo controller. I would have:
Foo.m (Model)
FooViewController.m (Displays a Foo)
FooController.m (Controls the logic)
And finally, to answer your question, I would store my references to Foo's in the foo Controller. I like to use singletons for my controllers, but thats just me. If you do use a singleton, you can just do something like this: [[FooController sharedInstance] listOfFoos] to get your Foo's
In my applications I usually rename the AppDelegate class to AppController, if that helps explain things better conceptually. Your app controller is responsible for creating and/or configuring the model controller (which manages your collection of model objects) and window or view controllers, setting up references between them if needed, and calling methods on these controllers in response to NSApplication delegate methods or high level action methods from the main menu. Depending on how complex your application is you might also have additional model or view controllers which are created outside your app controller.
Of course if you have a simple application there's no real reason not to have your app controller play the role of the model controller if you want. What you want to avoid is file with hundreds of lines of code, all doing conceptually unrelated tasks.
Traditionally the controller creates the Model and then initialises the View with that model. The controller then listens to changes in the model and view and coordinates the flow of the program through this. That would be my generic answer, maybe things in practice would be different for iPhone development.
Where, in an iPhone application should an application keep the references to it's Model Classes ( using the MVC approach) ?
The controller layer keeps references to the model layer.
So is the App Delegate a controller ? a model class ? none of the two ?
The App Delegate is a controller.
Where would you guys store the references to A and B ?
A and B are model classes that would usually be created and owned by the controller layer.
I would really like to know how would you guys use mvc to put together this application which only uses one View.
The purpose of the controller layer is to allow the model and view layers to be self-contained. The model shouldn't know anything about the controller or view layers. The view shouldn't know anything about the controller or model layers. The controller's job is to be a double-ended adapter to the model on one side and the view on the other.
I would set up your example app like this:
UIApplication delegates to AppDelegate.
If operation of your server class (A) is simple:
AppDelegate creates and owns instance(s) of server class A.
If operation of your server class (A) is complicated:
Create a dedicated controller class (C) to control the server.
AppDelegate creates and owns instance(s) of class C. One instance of (C) for each instance of (A).
Each instance of class C creates and owns one instance of class A.
AppDelegate creates and owns an instance of your ViewController class, which loads and owns your view.
It's not clear in the question what the purpose of class B is.
If it's a chunk of data that's for the use of A only (like config data or static website data), I would have it be created and owned by the server (A).
If it's data that is created during server operation and needs to be displayed in the view, then you will probably want something like:
A mutable array owned by A, to hold instances of B.
Another controller class (D) to reference that array and act as a datasource/delegate to your view.
I find that in most instances, AppDelegate provides a good place to place some base functionality (such as a a background image you want applied in every controller), but that you'll want to have additional controllers and model code elsewhere. A navController or rootController would often be placed as a property on your AppDelegate.
So, I would say that is somewhere between "neither" and "controller", but leaning more towards "neither". Definitely not "model"!