If I am using multiple viewControllers, do I need to create a separate UIViewContoller class for each one of them or can I associate this same new class with each individual viewController? Under what circumstances would I create a new class to associate with a separate VC?
thanks.
View controllers manage the logic of your view, providing a way to channel the data between the view and the mode, and react to events initiated by end-users through the user interface.
If multiple views happen to share the same logic of model-view interaction, it is a good idea to share view controllers among them. However, this is somewhat rare: in practice, different views call for different view controllers. So in practice you create a new class for a new view controller almost every time that you need a view controller. You can also start with several view controllers, and then unify some of them if you spot sufficient number of commonality in their code.
Related
Following this article There are two schools of thought with regard to whether the View interacts directly with the Model or not.
I'm interested in the case where View don't interact with Model. If only Controller knows about View but not View knows about Controller we can easily update View with Model data (write some text, for ex.) by calling View and Model methods in Controller.
But how could Controller and Model react to View changes (button push, for ex.) if View don't know about Controller or Model?
-One solution-
One way to make 2 objects communicate with loose coupling (in your case views don't know about controller and vice-versa) it to use a "messenger" pattern.
The 'messenger' is an object known by all the others. Using the 'messenger' object:
You register objects (your views) to send messages
You register objects (controlers, models...) to listen to specific messages
In this way, a model can react to a specific view's event because it is registered into the messenger.
There is a full example here (C# code):
Light messenger pattern
Tell me if it s what you were looking for...
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!
Being a relative newcomer to MVC I'm musing over a little problem. I'm developing a page which relies on a collection of my viewmodel objects. All good. But, as the page has relatively complex functionality I need to get at other objects or collections of the main domain model to display in the UI. Admitedly rather more light weight objects. What's the best way to achieve this?
What I do is create a custom class to encapsulate ANY data I need to display in any certain view / action. So for my Admin areas User controller, I have a AdminUserIndexViewModel class that holds my list of user business objects. I also put any other data I need to display into this class.
For my AdminUserEditViewModel (that corresponds to my Admin Area, User Controller, Edit Action) I might have a single User class, which itself has its Roles attached to modify if need be. If you need to put other information like user settings, or preferences, etc...
If they are not part of the viewmodel you are currently working with then you can use Html.Action to call into another controller method to render another inline view through a controllers method.
Can someone explain the relations between elements of MVC (with the active model), painted on this picture?
I see it like this:
Controller → Model — a model's data changing by the controller.
Model → View — the model notifies the view about changing.
View → Model — the view get data from the model.
View → Controller — the view notifies the controller about user's actions (for example, button pressing).
Controller → View — but this relation, as I think, is unnecessary and contradict MVC rule about developing the controller independent from the view: it should interacts through the model.
The MVC is rather broad subject, there are many variants of this pattern, and many implementations. I have seen solutions in which one of the responsibilities of a controller was to create an instance of a View with associated Model attached. This might be the relation you're looking for.
One other thing - existence of controllers independent from the view is a myth in real-life scenarios, in my opinion. Sooner or later you need to provide a functionality which explicitly tightens the View - Controller relation and is unusable (or simply different) without that particular View. Besides it is far more efficient to embrace the fact that different types of views behave differently and turn this into advantage by building tailored Controllers instead of pretending that we could deal with every aspect of user interaction with just one.
I think the relation between the between the model and view is wrong (at least the solid one). The way I see it in an MVC pattern is that everything goes via the controller. So in the view, the user selects the data he wants to see.This request is send to the controller. The controller is going to get the data in the model and the model gives back the requested data. The controller then sends it back to the view and the view outputs it to the user.
As for the controller->view relationship you have highlighted
The controller needs to be able to choose the appropriate view that is displayed
AFAIK, that is the only relationship the controller has with the view (aside for the view routing messages to the controller). MVC is a little different from MVVM/MVP because you don't necessarily have just one view for each controller. For example, you could have a user controller and you might have a view for displaying information, one for editing users, and one for adding users. With the other two methods, there is a one to one relationship between views and ViewModels or Presenters.
Controllers being independent of the view is not a myth
Maybe I haven't used MVC enough in other scenarios but I have always kept the controller independent of the view. In fact if you have any view code in your controller (ie function with ListBoxEventArgs, referring to view components, etc) then you have not achieved the goal of this pattern which is to separate your view from your logic and model. I believe ASP.NET MVC makes views completely independent of the controller by having some class that manage tracking the initiated views. This class is available to all the controllers (through inheritance but dependency injection is fine too) and then each controller just picks a view to display using this class. The view can be selected with a constant or a string (in fact, I believe it is even possible to select them with no argument and based on the method name).
view->controller relationship
With ASP.NET MVC, view's are independent of the controller too since events are routed to the controller via url. However. in other non-web situations, it is fine to just forward your events to the controller by directly calling controller methods in the code behind.
Implementation details
On my blog, I wrote an article that covers the implementation of MVC a bit and should help answer your questions.
MVVM vs MVP vs MVC: The differences explained
Personally, I think the type of MVC shown in your diagram is not being employed as often today as in the past and it might be hard to find examples that use those relationships as shown. The reason is that if the view is able to talk to the model, then I think developers will opt for MVP or MVVM (and use a view model) over MVC. The only case I can think of where the view is not able to continuously talk to the model is in server client situations. In this case, there are many popular MVC frameworks like ASP.NET MVC is still popular today.