I am developing an document based application using MVC pattern, my model object is Mutablearray of mutableDictionaries. Each dictionary in the array is represented to the user by a View object. (for example if the array contain 100 dictionaries then 100 views will be addsubviewed to self.view)
I learned that in MVC pattern the view and model should not know about each other instead they must respond via a Controller object(UIViewController).In my application I followed the MVC pattern but I did not follow the one I mentioned here because by holding a reference to the model object(NSMutableDictionary) I can easily modify the model object(as the user edit the view object) and then write the array of NSMutableDictionaries on the disk after the user finished the document.
Tell me If I should isolate model and view if so what benefit I can avail or I can go on with that
Related
I wonder 4 questions about the data model when creating iOS apps:
Do you create a class called DataModel and inside there we find arrays and objects that belong to the data model that is instantiated by every model? Or do you create a data model that is a singleton and has the app state? I guess singleton is not a good idea because is difficult to test.
Where do you write your networking code and mapping code (converting json files into data model objects)? I guess it should be an object inside the data model.
I understand the model encapsulates app state, for that reasonI I guess if we have a table in controller A and the detail in controller B (using a navigation controller), maybe we have to create an instance of the data model that holds ‘selectedStudent’ and then once the B controller is pushed, it uses the model to know what student was selected.
That’s what I understand from this image:
http://naikom.ru/img/2012/ios2/8.jpg
However from this image;
https://littlehales.files.wordpress.com/2012/01/mvc2.jpg
I see that there are several models and controllers communicate each other, so in my example, using prepareForSegue I could pass the selectedStudent to the other controller. If we do that, then the controller is encapsulating state, rather than the model.
Can you explain to me how I should do that? Or how do large apps do this?
According to this diagram:
http://i.stack.imgur.com/Psi8i.png
In order to send information from the data model to the controller we have to use NSNotificationCenter or KVO.
I know the problem of delegates is that they are just a 1-to-1 relationship, so probably not good idea. What about blocks or creating your own observer using a protocol and addObserver/removeObserver (using an array or a set)? Do you really use for this NSNotificationCenter or KVO in the data model?
There are different levels I'm asking this question at.
Case 1: Let's think about the typical drill-down design. Say a table view controller has an array of custom objects, and tapping a cell will push a view controller that allows the user to modify the object represented by the cell. In this case, should the pushed view controller have the custom object as a property of its own, or use a data source/delegate protocol to edit the custom object but not own it.
Case 2: A similar but slightly different situation is this. I'm using a singleton store to handle an array of bank accounts in my app. A view controller will show a list of the accounts, and I'm wondering if I should have the array of accounts as a property in my view controller or get the array via the store. (The array of accounts is accessed quite often.) I guess the only difference is a single object vs. an array of objects. I'm curious about how heavy these arrays can be, so whether it's faster to load the array from the store each time or have it as a property in the view controller.
Case 3: When should the local file system be used? In my app's example, bank accounts are accessed quite often, so I have them unarchived and set as properties upon launching the app, but for much bigger data, I only load them from the file system when they should be displayed or edited. I'm still not sure what the right way is.
I have a data controller class used within my app that handles parsing xml and a few other operations vital to my app. What I want to be able to do is have the data that it parses store in an array that can be accessed in multiple views of my app. Right now, each view creates its own instance of the data controller class and so the array that the data is stored in is specific to that view controller. Is there a way to still create individual instances of the data controller class for each view controller, but the data is stored in the array where all views can access it? I have tried to store in NSUserDefaults but that doesn't seem the most effective way. Each view controller needs to have its own instance of the data controller class because I utilize delegate methods that are used in each of the view controllers. I hope this makes sense.
You have two ways to implement this (ok, maybe more than two but those are most common):
Store array in application delegate and acces it as property.
Create singleton object who gonna hold array (and other possible data/methods).
For simplicity in an example, lets say I have data classes from an object model with the following hierarchy:
Author
Book
Chapters
Each of these data classes only contain references to instances for their children, not their parent, for their parent they only contain the Id. For example, Book has Book.Chapters, but it does not have a reference to its parent (ie: Book.Author), instead it has the Id of the parent (ie: Book.AuthorId).
Now I want to display 'breadcrumbs' for this hierarchy in my view. But to do so, I need to get information such as Author.Name, Book.Name ... So as I see it I have the following options:
Create custom models for each view. ie: new SingleBookViewModel { TheAuthor = DB.GetAuthor(book.AuthorId), TheBook = book }
Get the data in the view itself from the book. So if I have the book view for example, I would be able to use: Author author = GetAuthor(book.AuthorId)... and do this within the razor view itself.
Pass the data in using the Tuple class. So for viewing a chapter I populate the Model with a Tuple with the following signature: Tuple<Author, Book, Chapter>
Which method would you use? Or would you use something different?
Currently I am using the third method, with the Tuple.
The 2nd method is likely the most 'standard'. But I dislike the idea of having to create and maintain view model classes that correspond to each of the data classes (Author, Book, Chapter) behind them.
I'd like to understand what 'best practices' people have put around something such as this... and whether using Tuples makes sense.
I would implement this with ViewModels. Each of your views will be strong typed to a ViewModel that will contain all data needed for that view. You get a collection of Authors in that ViewModel, which contain a collection of books, which contains a collection of Chapters.
As an alternative you can bind your View to a collection of Authors, and upon selection of an author make an ajax get request to a controller's action that returns the books in Json format. The same would apply to the Chapters.
I'm not sure if there is a difference in these two methods. If so, which would be considered the better practice when submitting more than one object to the View.
Having the controller make separate calls to the datalayer for each object model and then wrapping the objects in a model to send to view.
Defining a "presentation" model and having the controller call that single model to send to the view.
other...?
I'm assuming here that you have a view that presents some information from more than one model, perhaps in a list format. For example, you may have a model of a customer which has a set of contacts, but in your list you want to choose to show some of the customer details along with the name and phone number of the primary contact. What I would typically do in a situation like this is define a specific "presentation" model that consists of just those details that I may want to show in this combined view. It would typically be a read-only model. Using LINQ to SQL I might even define this as a table-valued function (to support search) and associate it with a view that encapsulates the join of the various tables. With both you can add the view-based "presentation" model to your DBML and associate the table-valued function with it as a method on the data context.
I prefer doing this because I believe that it is more efficient in terms of queries to construct the query on the server and simply use it from the code. If you weren't using the table-valued function for searching, you might be able to construct the query in code and select into a "presentation" class. I would favor an actual class over an anonymous type for ease of use in the view. Getting the properties from an anonymous type in the view would be difficult.
You should send to the View a single object, sometimes termed a ViewModel object, containing all the data (including domain model objects) that the view will need.