I have read Apple's MVC article and am confused about various things. Firstly Apple uses a combination of the View and the Controller in almost all its sample applications which is fine and I like it but they contradict themselves in this article because they said that View's should not rely on Controllers etc.
My main question is does anyone have a link to one of Apple's sample iOS projects which is a good example of the MVC pattern - with data retrieval etc because I don't fully understand the Model part of the pattern.
I don't understand the difference between a 'domain object' and a model object. For example if I wanted to retrieve a list of orders this would happen in a model class Orders. Would I then have another class Order which has properties such as OrderDate, OrderNumber etc or how would this work?
This sample code demonstrates a multi-stage approach to loading and displaying a UITableView. I think it's really interesting to dive in. It will show MVC in the works.
Here’s how the Model-View-Controller (also known as MVC) pattern maps to the main parts of your App:
Model → Data
View → User Interface
Controller → Core Logic
this explain fully with sample code
http://www.hollance.com/2011/04/making-your-classes-talk-to-each-other-part-1/
I believe that the following code will help you understand how to work with MVC in iOS application because its description says:
"MVCNetworking is a sample that shows how to create a network
application using the Model-View-Controller design pattern.
Specifically, it displays a photo gallery by getting the gallery's XML
description, thumbnails and photos from a web server, and uses Core
Data to cache this information locally."
http://developer.apple.com/library/ios/#samplecode/MVCNetworking/Introduction/Intro.html#//apple_ref/doc/uid/DTS40010443
The model is the brain of the application. It does the
calculations and creates a virtual world for itself that can live
without the views and controllers. In other words, think of a model
as a virtual copy of your application, without a face!
A view is the window through which your users interact with your
application. It displays what’s inside the model most of the time,
but in addition to that, it accepts users’ interactions. Any
interaction between the user and your application is sent to a view,
which then can be captured by a view controller and sent to the
model.
Controllers in iOS programming usually refer to view controllers. Think of view controllers as a bridge between the model and your
views. They interpret what is happening on one side (what the user
does on the view side, or the information provided by the model) and
use that information to alter the other side as needed.
This is by far the best, yet simple explanation I've come across(taken from RayWenderlich)
"The idea behind MVC is that
- VIEWS should only care about how they are presented HOW THEY ARE PRESENTED,
- MODELS should only care about their DATA, - and CONTROLLERS should work to MARRY the two WITHOUT necessarily knowing too much about their internal structure."
Related
Background:
We're using Caliburn.Micro 3.0.0-beta2 with a WPF + Xamarin iOS / Android project and we want to ensure the view models can be cross platform to reuse as much code as possible.
We've been looking at how to abstract our our navigation to be testable, cross platform and so callable in the view model rather than the views.
I was wondering if anyone had suggestions about how we should handle our app navigation. Our screens require us to inject some data such as database ID's into screens as we're navigating around. Currently we've done this with a view first approach by injecting the data into the view and having that pass it into the view model, but this doesn't feel ideal as it should really go into the view model as it's view logic (right?).
The view model is created for the view view using ViewModelLocator.LocateForView(this); and this then satisfies the rest of our dependencies using the SimpleContainer.
We Understand that navigation hasn't been implemented into 3.0.0 yet according to https://github.com/Caliburn-Micro/Caliburn.Micro/issues/142. We're really looking for a way we could do navigation that may be similar to the Caliburn.Micro solution implemented soon, with a hopeful view to contribute towards this if possible.
Questions:
How would we go about getting the data into the view model rather than the view to make it easier to test and more similar to how our WPF application will need to work?
Is this even sensible for a mobile app or should we be taking a view first approach? If so, what would be a testable approach for this?
Unless you have setup Caliburn.Micro for view-first approach (can be done there is a sample for this) the framework is almost completely viewmodel first in nature. I find it rather difficult to work in view first. Most of my "screens" are developed around the view model in question. With that in mind I also at times have multiple views for each viewmodel depending on the operation (add/ edit/ details/ list) for example.
1) DI, usually through repository or other context of that nature then using BindableColllection to hold and notify of changes to the view. Pretty much the same as WPF would work. Most recently my code has started to be cross platform (WP to WPF, now more Universal) to help reduce my headaches. Most of the patterns used are DI(SimpleContainer), Repository (EF 6x), Pub/Sub (IEventAggregator). The one exception is Repository but to an extent I still use it on WP but since I use Sqlite, up until recently EF was out of the question (EF 7 to the rescue)...
2) Do what is comfortable. If you are use to using Fakes then do it. It shouldn't matter as long as you have the correct results you are looking for in the end. Of course I am sure each test is going to be slightly tweaked for the platform they are tested on. Since each platform has its own nuances that you have to take into account.
I am new to knockout.js. Few moments back I read the headline features of ko.
I could not understand is ko really MVVVM? Because all they talk about is data binding and the ease of it. But I am sure MVVM is more than data binding isn't it?
Yes, knockout.js does apply the MVVM pattern. It's explained in the documentation:
A model: your application’s stored data. This data represents objects and operations in your business domain (e.g., bank accounts that can perform money transfers) and is independent of any UI. When using KO, you will usually make Ajax calls to some server-side code to read and write this stored model data.
A view model: a pure-code representation of the data and operations on a UI. For example, if you’re implementing a list editor, your view model would be an object holding a list of items, and exposing methods to add and remove items.
Note that this is not the UI itself: it doesn’t have any concept of buttons or display styles. It’s not the persisted data model either - it holds the unsaved data the user is working with. When using KO, your view models are pure JavaScript objects that hold no knowledge of HTML. Keeping the view model abstract in this way lets it stay simple, so you can manage more sophisticated behaviors without getting lost.
A view: a visible, interactive UI representing the state of the view model. It displays information from the view model, sends commands to the view model (e.g., when the user clicks buttons), and updates whenever the state of the view model changes.
When using KO, your view is simply your HTML document with declarative bindings to link it to the view model. Alternatively, you can use templates that generate HTML using data from your view model.
In addition to the answer already provided, there are a few things to keep in mind -
MVVM
Knockout is MVVM because it supports a good separation of concerns. Unlike other JavaScript libraries, such as jQuery, it's goal is to not pollute the view with that which does not concern it.
The view model's purpose is important to understand. It does not attempt to manipulate the DOM because only logic required to serve up data to the view is placed inside of it.
The view's purpose is only to present (render) the data. No logic, validation, or other logic code goes here.
The model is the only place where Knockout can get a bit tricky. It is generally a good accepted practice to place a separate model in your project for Knockout to use, but many developers have found the ease of mixing the model into the view model. The reason for this is obvious (some models are very basic) but again this is only out of ease of implementation.
MVC vs MV*
Surely there are other answers on SO.com that attempt to answer what is MV*, but I wanted to throw my $0.02 in here - Other libraries or frameworks speak to the fact that they are MVC or MVP or MV(whatever) based but Knockout is the only one that I have found that practices what it preaches in this regard. If you have the time and desire look at the structure of other frameworks such as Angular or Ember and you will see there is a blurred line that exists, and more or less they are simply using an MVVM based pattern but calling it something different.
Well I guess it can, however I am working on a project where all styling and UI layout manipulation is done in the knockout js ViewModel file, which is not good practice.
I'm over-thinking this and getting myself into a muddle but can't clear my head.
I'm new at WPF and I'm trying to get familiar with MVVM. I understand the theory. I need a view, a model and another model (called the view-model).
However, what happens if my model is constructed by a parameter of the View's constructor.
So, assuming I have a totally empty project, the only thing is I've an overloaded MainWindow constructor which takes the model:
public MainWindow(Logging.Logger logFile)
{
InitializeComponent();
this.DataContext = logFile;
}
The Model is the logFile. Can I still implement the MVVM when I don't have a separate Model class?
Any thoughts would be appreciated.
You're overthinking this.
There are several components to MVVM:
View:
The view provides a, well, view on the data. The view gets its data from a viewmodel
ViewModel:
The viewmodel is there to organise your data so that you can organise one or more sources of data into a coherent structure that can be viewed. The viewmodel may also perform basic validation. The ViewModel has no understanding of the UI so should not contain references to controls, Visibility, etc. A viewmodel gets its data from services.
Services:
Services provide data from external sources. These can be WCF, web services, MQ, etc (you get the idea). The data the service returns may need to be shaped so that it can be displayed in the UI. To do this you would take the raw data from the service and convert it to one or more Model objects.
Model:
A model object is an object that has been created so that it can be easily displayed/work with the UI.
You may find that you don't need to shape your data coming from your services (lucky you), in which case there's no need to create model objects. You may also decided that you don't want your services talking directly to your viewmodels but instead what to have them get their data via a "mediator" object. That's also good in some situations (usually when you're receiving a continuous stream of data from a source/multiple sources).
MVVM is a bit like porridge: there are lots of potential garnishes you can add, but you don't necessarily need to add them all. Or want to.
Does this help?
Edit: just stumbled on this: a more in-depth expression of what MVVM is:Mvvm Standardisation. This may also be useful
The Model is something the ViewModel will know about but not the View. If you need to present info about a Logger, you can certainly have a LoggerViewModel that knows about a Logger, and in turn the View winds up getting to know about the ViewModel. There are several ways to do that, and setting the DC in the view constructor is one of them.
After that basic understanding of who knows about who, what really makes the MVVM architecture pattern, IMO, is that ViewModel communicates to the View via databinding. Nothing more and nothing less. Lots of goodies come out of this, but that is the crux of it that makes it different than other separation of concerns patterns (like Presentation Model, MVP, etc)
That said, you need to get a feel for it by working through some sample projects. Asking questions here on SO is fantastic when you get stuck on something, but you must realize your question here is a bit fuzzy at best. Also, unless you are really looking to present logging info in your view, logging is not an MVVM concern. Its interesting alright but not MVVM.
Google Josh Smith's MVVM demo on MSDN for a perfectly meaty yet approachable beginning sort of project. And ask more questions or refine the one here as they come up!
HTH,
Berryl
forget the view! at least at the beginning ;)
try to think about what you want and what you need. what i understand is that you wanna handle a logfile. so you need a viewmodel for that.
public class LoggerViewmodel{}
you can put the logfile as a parameter to the vm ctor. now you have to think about what you wanna do with your logfile? for everything you want create a property (LastModified, LastRow, whatever) on your viewmodel.
btw there a two different ways to do mvvm, first is view first and the other is viewmodel first. i do both in my projects and take the appraoch wich fits better (viewmodel first the most time ;)) to my needs.
pls edit your questions and add what you wanna do with your logfile, then we can give you a better answer.
edit:
Can I still implement the MVVM when I don't have a separate Model class?
to answer your question the short way - yes you can. you have to seperate the view and viewmodel and use binding to bind the view to the datacontext(viewmodel).
I am currently using caliburn.micro in my WP7 project and I am quite happy with it. My application is very data-heavy, so I took a look at Agfx (http://agfx.codeplex.com), seems it can save me a lot of time on data requesting and caching.
But the problem here is that agfx also provide a base view model, while I've already had one which inherits Screen of caliburn.micro. Of course I can encapsulate a new view model base which inherits ModelItemBase from agfx, and implements IScreen. But I kinda don't like this, is there any better soultion or best practice you can share with me about how to integrate the 2 great frameworks?
Best Regards,
-Peng
I am actually using AgFx with another UI framework which has its own ViewModelBase. My own understanding is, the ModelItemBase that's provided by AgFx is a model base rather than a viewmodel base. It basically takes care of the data.
My viewmodel which inherits from my ViewModelBase, does a lot more stuff like Tombstoning, application bar bindings, etc. It's designed for displaying the data on the view.
I think it fits in mvvm and works out really well. Hope this helps. :)
In my current MVC2 project I implement my MVC by creating a "model" class that gathers data from the database and runs it through business logic, etc. Then I have a "Controller" that gets the processed data from the model and sets the values in a "ViewData" class. This "ViewData" class is a class of getters and setters. This ViewData is then passed to the view in the Controller like this : return View(myViewData);. Finally, in the View, I bring in the data stored in the ViewData by putting this line at the top of my aspx file.
<%# Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage<Core.UI.Web.ViewData.MyViewData>" %>
So, is this the way MVC3 is done? I have a guy on my dev team that is suggesting that the model should be sent, via the Controller, directly to the view like this: return View(myModel);. His reasoning is that this is MVC not M.V.VM.C.
I understand that ViewBag can be used but that just seems like a quick data container.
So, in other words. ViewData or no ViewData?
Thank you,
Aaron
There are certain situations where you might want a view model: to combine data from multiple models/sources, or for specific validation scenarios, etc., but, it's perfectly acceptable to have your view take a model without an intermediary view model, especially if the view model is just a class of getters and setters with no other functionality.
If you're not concerned about exposing methods/properties from your domain model (or if it doesn't apply), I would just pass the model straight to the controller.
In your instance ViewData is just a model - it is a ViewModel and is perfectly fine, and actually the recommended approach in general to use. The reason being you dont want for instance, a primary key from a customer model rendered in the case of a "create customer" function - as a customer id doesnt yet exist. However for editing a customer record, you surely need a key. So - if you use viewmodels in some cases and not in others, not you are inconsistent in your project.
'yes' you can - but I prefer consistency and using a view model gives you the consistency.
You can also use the model - and thats normally how the MVC demos are setup, but unfortunately like most demos, they don't give you what is architectually best, but what is best in whipping together a 5 minute application.
As other have said, although you can get by passing Models to your views, sooner rather than later you'll find yourself wanting to add properties for display purposes only that don't quite belong to the model (e.g. values depending on the current session rather than the model itself.) When you hit that point and it's usually pretty soon you'll be glad you used viewModels.
Technically speaking ASP.NET MVC is not even using MVC but rather Model2. Dino Esposito has a good article about this. Furthermore, on his book Microsoft .NET: Architecting Applications for the Enterprise he even goes as far as saying:
"It is a sharp and bold statement, but we have to make it: today classic MVC is gone. However, some of its variations are healthy and thrive. They are Model2 for the Web and MVP for both Web and Windows. In turn, and only more recently, MVP has undergone a facelift. In July 2006, Martin Fowler proposed to retire MVP entirely and replace it with two variations Passive View (PV) and Supervising Controller (SVC). “
I wrote a review of this chapter on my blog.