In an MVVM application, is it be frowned upon to have a viewmodel without a view?
My justification for having such a viewmodel is that the underlying model fires some events caught by the viewmodel which then in turn notifies other viewmodels of this event using an event aggregator.
In MVVM, ViewModels must be independant of Views. So, YES, a Viewmodel can be without a View.
Related
If we say that View and View Controller can be considered as View in MVVM, then shall we use Delegates in ModelView (which is for business logic).
Generally, if it's a view's delegate - put it in the View Model. If it's model-level delegate not related to the UI, implement it in the Model.
your question is pretty unclear, but I can still provide an outline / guideline for you.
Typically as your apps evolve with more complexity, you'll need view models for each of your views that can be customized and described by data. You want your view controllers to be clean and very readable, and as a result, you should only use view controllers as containers for your custom views. Your custom views can have a view model property with a didSet that allows it to modify and configure the view. For example, when I dequeue a cell from a tableView, I would give the (cell as? MyCustomCellClass)?.viewModel = aViewModel to make it extremely readable. You use delegates to handle business logic by setting delegates appropriately to communicate between a subview and a view, or from a tableViewCell to whatever controller is managing and extending the UITableViewDelegate or UITableViewDataSource. So all in all, your MVVM architecture will rely on custom View Models that you can use to configure your custom views, while you have controller objects managing business logic and handling the flow of data between things at a lower level with things at the higher level. If you have a specific example you'd like help with, please post some code. Hope this helped!
I have an abstract base view model (IBaseViewModel) and two classes that implement it (Base1ViewModel, Base2ViewModel). I also have a Xaml user control, and I want in one page to use Base1ViewModel as view model and in another page Base2ViewModel as view model.
Prism best practice is to bind to view model by name, so what I ended up doing is duplicating the xaml file into Base1View and Base2View so each view gets the right view model, but this is obviously not ideal because then changes to the xaml should be duplicated as well.
Is there a solution/design in which I can reuse the same xaml user control with two different view models?
Thanks,
Noam
On the MVC paradigm, a view can only communicate with a controller, and via a blind communication (target-action or delegate/dataSource). I understand that, but is it a violation of MVC if a view communicates with another view, using a delegate?
Almost always. The delegate of the view should never be another view. It should be a controller. The controller is the appropriate place to drive changes in the other view.
A view should almost never say something that another view would care about. A view should say to its delegate things like "I was touched." Why would another view care? It's up to the controller to say "ah, a touch here means that I should move the active focus. I should tell the current active view to let go of focus" (as an example). I view is not responsible for determining what events mean in the broader application, only what events happened, and so are very unlikely to generate messages of interest to other views.
My opinion on this is to use the observer design pattern and simply use notifications (NSNotification)
I am a novice myself. But I would think that it's not. A jsp page when called could just redirect you to anothr jsp page. I have seen that happen sometime. So I guess it is in a way, a view calling another view.
Can I have multiple ViewModel for a View in WPF? Because some times we need to show the view only in simple view format and sometimes the same view has to shown in editable format. Hence we can create seperate view models for each.
So is there any way to hook 2 diffrent view models to a view?
A ViewModel should serve as the Data Context for your View, so that would only allow a single VM.
There is no reason why you could not break you View up in to multiple UserControls, each with their own ViewModel.
Generally you're going to bind your View to a single type of View Model. That's not to say that your type couldn't be an interface, or a base class from which both of your views inherit.
I tend to only use an interface or base/derived class situation when I have a single view model type that is going to span several different views. For example if I have two different types of forms that display widget information, I would create a single base Widget ViewModel class.
In your case, it sounds you should either a.) create two views for your simple and advanced views or b.) simply use a single ViewModel class.
I'm implementing a datasource object for an UIScrollView. Is that part of the Controller, or part of the Model? I think Controller, but not sure. It delivers the data. But the data could be in sqlite3, files, from the net. So actually I would say it's not from the Data part, since it should be flexible to from where the data comes. What do you think?
The data source for any visual control should be your controller. Your controller should get/process the data from the Model and then hand it off to the view.
I would say it is actually neither. Your UIScrollView datasource is simply formatting your data for display.
Unless you have specific actions that perform "business logic", your UIScrollView datasource participates in the View.
The Controller would include logic that modifies or processes data in any way, your scrollview simply allows the data to be displayed.
Cocoa's MVC paradigm encourages both "model controller" and "view controller" objects. The data source object falls in the view controller category; it requests model objects from the data store depending on what UI element needs them, reformats the data a bit to fit , and passes it on to the UI. Usually the same object will also handle UI events and delegate methods.