I've made a TPH inherited model (in my case a party concert from a regular concert), my question is do I have to create an additional controller with view for the inherited model?
If yes, can I inherit said view or at least not have to rewrite the entire view? Also a bit of the database storing question is the TPT better than TPH or TPC?
Related
I am looking for a solution/mvvm framework that supports nesting ViewModels and Views. What I mean is:
Each ViewModel derives from BaseViewModel
ViewModels have properties that are of type BaseViewModel which are sub-ViewModels (nested inside parent ViewModel)
Each ViewModel have corresponding View
Views have ContentControl (control that can display templated view) corresponding to sub-ViewModels of corresponding ViewModel
Now, when creating instance of ViewModel it is needed to pass appropriate instances of concrete sub-ViewModels. Views should be automatically resolved and nested (somehow) base on ViewModels structure.
I do not define somehow because there may be a lot of ways to do it.
I hope my idea is clear. This approach allows easy and dynamic creation of ViewModels and Views. Just create tree of ViewModels, for example in XML, and base on this create new functionality.
The questions are:
Is there any mvvm framework (mvvmcross, catel) supporting such approach for Xamarin.Forms?
How would you store tree of ViewModels - in XML, database tables, ...?
How would you create instances of ViewModels - deserialization, dependency injection, ...?
How to create Views and resolve (if framework does not support it)?
After some time I can share some experience about the questions I asked:
I do not know whether there is any mvvm framework supporting such approach. Probably Catel v5 is going to support this, but I did not checked this. I use custom solution.
In my solution I store ViewModels definitions in single database table in parent/child structure.
ViewModel instances are created by custom factories using definitions from database table.
Views are created using ValueConverters. It is possible, because each view has bindings created base on ViewModels structure.
Beside above answers I can suggest to use Prism. Although it has some disadvantages for me it is the best framework in such approach.
Yes! There's an MVVM Framework that fits exactly to what you are looking for and is created with Xamarin.Forms in mind:
FreshMvvM: https://github.com/rid00z/FreshMvvm
Quickstart Guide: http://www.michaelridland.com/xamarin/freshmvvm-quick-start-guide/
How does it compare to other options?
It's super light and super simple
It's specifically designed for Xamarin.Forms
Designed to be easy to learn and develop (great when you are not ready for RxUI)
Uses a Convention over Configuration
Features
PageModel to PageModel Navigation
Automatic wiring of BindingContext
Automatic wiring of Page events (eg. appearing)
Basic methods (with values) on PageModel (init, reverseinit)
Built in IOC Container
PageModel Constructor Injection
Basic methods available in Model, like Alert
Built in Navigation types for SimpleNavigation, Tabbed and MasterDetail
You can nest or derive ViewModels as much as you'd like (In our case we have a BaseViewModel). We have been using FreshMvvM for our startup and has been battle tested to work and fit to whatever we need.
I have done some research online and I have come up with some conflicting answers. Here is my situation:
I have a EditClient view which references the ClientViewModel and I have an AddClient view which also references the ClientViewModel. Naturally, edit and add operations are different and the logic in the ViewModel differs somewhat.
Would it be appropriate to have an EditViewModel and an AddViewModel and have them referenced by their respective views? Is this considered valid MVVM structure?
Thanks!
Yes, i would have one ViewModel per View. But the ViewModel would of course work with the same Model.
I have been reading a lot about MVC these days and I think I have my head around it but I would appreciate some advice and informed opinions on how to best approach my problem.
I have 3 questions really all related to the MVC design pattern.
In many of the examples I have encountered people have used the contoller (say of a Table view) to populate an array with objects of a custom class (say Student.h/m).
But shouldn't the Student class have methods that are called that would return an array of data for the variable in the controller? Isn't that how the MVC works? That the model holds the definition of the data and takes responsibility for reading and writing it?
In many table view examples, in the various books I have read, they all say, "for convenience we are going to make the controller our delegate and data source for the table". I have yet to see an example where table view does not use the controller as a data source. How would you hook up a table view to a different data source?
I have 2 model classes "mission" and "airfield". Each one of these needs data from a XML file in the cloud. Do I write the parser in the mission/airfield implementation files? Do I create a separate Parser object? Should these models retun data to the controller as an array?
Whilst I understand a lot of the theory a lot of the examples I find on the web seem to break a lot of the concepts I thought I understood.
Any explanations would be most welcome. The quality of responses on this site are amazing.
Thanks in advance
You seem to already have a pretty good understanding of how MVC works, so I'll just add a few comments.
The controller is responsible for feeding data to the view.
There could be a million different states and scenarios that would affect what data to use and how, and it's not the model's job to figure that out. The model holds the data, and the controller handles the logic.
If you need a different delegate or data source for your table view, you can instantiate them in the table view controller, and then tell the table view about them using the delegate and dataSource properties. They need to implement the required methods of the UITableViewDelegate and UITableViewDataSource protocols.
Sometimes models and controllers overlap in functionality, and this is a perfect example of such a case.
One solution could be to let the mission and airfield classes inherit from a custom class that knows how to download the required XML and set up a parser, so they just need to provide the URL and override the parser callbacks for their specific tags. Everything else related to downloading the XML could be handled in the super class.
Another way could be to create a separate class that takes a URL and returns some XML, and then the mission and airfield classes call that method and parse the XML independently.
The wrong way is to let both the mission and airfield classes know how to download and parse, because you'd have to maintain the code in both places.
It's OK to have a data loading controller, that hands over the data to the view controller, so the controller code can be very specific (and maintainable).
I have a layout which works fine. This layout contains several partials, which display adverts, a side column a slideshow, etc. All of these are likely to change depending on which page (module/controller/action) of the site you are on.
What is the best way of doing this correctly? In the past I have assigned variables to my view inside my controllers, these are then passed to the partial which then displays the correct slideshow or advert. This seems ugly and not entirely correct for an MVC application.
Does anyone have any other methods of doing this?
Partials are just another view scripts.
My advice is: newer put your logic into the view scripts. Your may store the logic in:
models (remember, that you can create your own models, extending, or not extending the basic database models, eg. data hydrators)
view helpers (with parameters)
services (dependent on models, returning models)
combination of the above
Then use view helper or pass the ready data (model) to different partials.
Tip: Dependency injection is a good thing.
I'm using MVVM in a WPF app. I'm very new to both. Let me state that I am not a purist in the MVVM pattern, I am trying to use as many best practices as I can but am trying to make what I think are reasonable compromises to make it work in our environment. For example, I am not trying to achieve 0% code in my View code-behind.
I have a couple of questions about best practices.
1) I understand I don't want my VM to know about the attached View, but is it reasonable for the View to have a reference to its VM?
2) If a control in a View opens another View (such as a dialog) should I handle this in the View? It seems wrong to handle it in the VM since then the VM has some knowledge of a specific View.
1) The View has definitely a reference to the ViewModel through the DataContext. And you are allowed to cast the DataContext in your View:
public class ShellView : Window
{
…
public ShellViewModel { get { return DataContext as ShellViewModel; } }
This isn’t a violation with the Model-View-ViewModel pattern.
.
2) You are right. A ViewModel shouldn’t open another View. A better approach is to use Controllers. They are responsible for the Workflow of an application.
If you are interested in more detailed information then you might have a look at the WPF Application Framework (WAF).
1) Here are two simple practices for View's "knowing about" a ViewModel. It's reasonable for a View to know about a ViewModel (for Data Binding) -- but you may not need it in your case. See if either of these approaches help solve your problem. There are other ways, but these should be simple enough:
public View(ViewModel vm)
{
View.DataContext = vm;
}
public Bootstrapper(View v, ViewModel vm)
{
v.DataContext = vm;
//or, if you want it to have no parameters
View v = new View();
ViewModel vm = new ViewModel();
v.DataContext = vm;
}
The first option isn't bad if you have a service location tool, but there is a flavor of MVVM that doesn't like any code in the View's Code-Behind. The second option isn't bad either, should be simple enough for your task.
2.) This question can be a bit of a sticky point in MVVM design. If we are talking about a general Win32 MessageBox, I will often separate that logic into an additional object and put it in the VM. This way tends to a little more clear. (For example, I have selected an item in a ListBox, I have attached a Delete ICommand to that action, and in my ViewModel when this ICommand is Executed, I will poke my MessageBoxObject to ask if the user "wants to really delete" this item). More advanced "Dialogs" would use additional ViewModels and DataTemplates for those ViewModels. I prefer the Mediator approach.
1). The view will need a reference to the view model at some level, since the viewmodel will act as the view's datacontext.
2) One way to handle this is to have a generalized viewmodel representing a dialog, that is owned by the main viewmodel (the one being used as the views datacontext.)
You can use a command to crate a new instance of a dialog viewmodel, which will have a corresponding datatemplate defined in your resources. This template will be set to bind to the dialogviewmodel type.
Quite late, but I think this is tricky enough to deserve lots of different perspectives.
I understand I don't want my VM to know about the attached View, but
is it reasonable for the View to have a reference to its VM?
As already answered, a proper View-ViewModel arrangement involves the ViewModel being assigned as the View's DataContext property. That allows DataBindings to be "automagically" established from declarative XAML, or fine-tuned via code behind.
Sometimes, you'll be tempted to write, in your code behind, something like this:
var dc = DataContext as CleverViewModel;
CleverViewModel.CleverProperty.Add(someValue); // just a simple example
I believe the proper way to achieve this sort of things is NOT to cast DataContext, but instead:
Have some dedicated control in View, for example an ItemsControl with its ItemsSource two-way databound to some property in viewmodel:
<ItemsSource x:Name="cleverControl" Visibility="Collapsed" ItemsSource="{Binding CleverProperty, Mode=TwoWay}"/>
Cast the bound property instead of the whole ViewModel, in code behind:
var collection = (ObservableCollection<double>)cleverControl.ItemsSource;
collection.Add(someValue);
Note the important difference: the second approach in this example doesn't require the View to know the ViewModel type, it only needs a property named CleverProperty of type ObservableCollection<double>. This allows me to have polymorphic or even duck-typed ViewModels.
If a control in a View opens another View (such as a dialog) should I
handle this in the View? It seems wrong to handle it in the VM since
then the VM has some knowledge of a specific View.
This shouldn't happen in strict MVVM, and its not difficult to avoid using DataTemplates. DataTemplates map a given type of DataContext to a given type of view, so anytime the datacontext of a ContentControl changes, its display also changes, provided that you have a DataTemplate for that type:
A control in the view could send a command to the ViewModel, which in turn would update some of its own properties, that would be reflected by the view.
A View could contain another View, outside the knowledge of the ViewModel. In this case, the code behind can manipulate the datacontext of the contained view.
There are more subtleties, but I have been using this approach with good results. Hope this helps someone.
Build Your Own MVVM Framework
I found the approach suggested by Rob Eisenberg very interesting.
Key points:
Convention over configuration
ViewModel first
Which is very similar to ASP.NET MVC philosophy.
I highly recommend watching the video.