What is the best way to store static data in MVC application? Data like country and cities.
1- Should the data be stored in database and called everytime a view requests it and populate the dorp down?
2- Create partial view of countires and use it in different forms when needed?
3- Create static classes?
4- Create class and static method which returns the list?
5- Use caching?
Or any other idea would be appreciated.
Also the dropdown list should work with ajax, like selecting country should load the cities, selecting cites should load the region?
Hekim Başi
MVC stands for Model View Controller. Controllers 'control' your data, they do something with it, views are pretty much html, to show your data to users. Models are what you are looking for here, they store data in a way you can acces easily. As soon as you get the data you want, you store it in a model, then acces (and maybe alter) that data with your controller and finally pump it to your view, so the user sees your application.
Related
Im developing an iOS application and I'm stuck on how to design the structure of it. Here is what I have so far:
The app is called "Time Clock" and it allows users to clock in and out. The app will generate time stamps when a user clocks in or out respectively. As far as data goes, I already have a large MySQL database that is already being used for a similar Windows desktop application. (I'm trying to cater to my company's iPhone users)
My question is, what should I do about the data structures in this app? Can Core Data retrieve the MySQL data (through a web service) and manage it? Should I use data controller classes to manage the data? I don't know the best way to handle the data.
Here are the data fields that need to be managed:
Store
Name
PIN
Timestamp In
Timestamp Out
All in all, what is the most efficient way to manage the data in an app such as this? If you could point me in the right direction i would be very thankful! :-)
Core data wont be able to retrieve anything from a webservice, you need to make a data access layer that will return that data to you via NSURLConnection and the like, there is a lot of information out there on how to do this... I would recommend modeling some classes that basically your data layer will fill for the rest of your application to work with. Also if your data is shared across many views i would suggest making some singleton class that will keep the data already retrieved, this way you can access it across different UIViewControllers in your application. Way I would structure this is
DataAccessLayer (layer that consumes your webservices, and fills the info into classes (your model)) -> Some Singleton class that keeps your objects from your webservices -> UIViewControllers (these will talk to your data access layer/ Singleton class for the data it needs which in turn uses it to fill your views ->VIEWS - > if changes occur to your model relay that to your webservices via the data access layer
... As far as core data, you can use that if you want to persist the data in your application, but its not necesary otherwise, i should point out that core data is not the only way to persist data in your application... This answer is a bit general but hope it can point you to the right direction..
Daniel
I am creating an iPhone app that allows you to specify certain criteria, fetches a list of events from a web service, and lists the events in a table view so that users can add the individual event to their calendar.
How should I approach this with the MVC pattern? Will be using JSON.
Any ideas?
If you are going to be consuming JSON based web-services, you might want to check out AFNetworking. I wrote a network class to work with AFN, check out this SO post for the code.
User calendar and the list of events and how you fetch them is the model. Table view is the view. Classes that glue the two together are the controller. Doesn't matter if you use JSON or whatever else if we are talking about general architecture here.
I need to show data reading from local XML for a books app. I have to show data in different ways, eg. list of authors, list of editors, list of genres, etc then showing the book details.
Which is the best way to organize ViewModels? Can I have a single BooksViewModel class with the various GetAuthors, GetEditors, etc or should I have AuthorsViewModel, EditorsViewModel, etc?
Data is present in local XML and cannot change.
The ViewModel follows the view. So if you're having a separate view (page) for each type you wish to display the information for, then yes, several viewmodels makes sense.
But if your for instance, have a single view for all the data, for example a pivot, and then having a individual pivotitem for each data type, then you would use a single viewmodel, with several observable properties.
Does anyone know of a good way to start with a basic model but not use Core Data yet? I have a simple application that doesn't need to save any data (at the moment), but I don't think Core Data would be overkill for it.
I don't want to use the App Delegate to store data, nor do I want to store data in individual views. I was hoping to find some sort of "transitioning" type of solution that would let me switch over to Core Data in the future.
I've seen some simple examples, but they require storing an instance of the model within a particular view controller. I plan to have several views, so I want to find a better way.
The data model for an app can be as simple as a dictionary, or an array of dictionaries, or a plain old C-style array of characters for that matter. Or, to take it one step further, you might create a custom model class that not only stores the data but also knows how to manipulate it as necessary for your application.
How each controller gets access to the model is a different question. Some people like to use a singleton (I don't) so that they can access it globally. A (IMO) better approach is to instantiate the model in an object like the app delegate or root view controller, and then pass either a pointer to the entire model or a pointer to part of the model to view controllers as needed. An address book app might pass just a Person object to an address detail view controller, for example.
I'm an absolute beginner with ASP.NET MVC and I'm trying to build a pretty simple application, but I'm having a hard time getting out of the webforms thinking.
I need to register users so they can download my application. I need to capture their information in three screens. Rather than write the database from each view, I want to aggregate all of the data they enter and let them confirm it before they submit their information.
I've been playing with various models and such but if I make one big model, the scaffolding wants to put all the fields on one view.
Can anyone point me in the right direction?
Sounds like you need a Wizard. Here's a few samples:
http://highoncoding.com/Articles/647_Creating_Wizard_Using_ASP_NET_MVC_Part_1.aspx & a youtube video
http://shouldersofgiants.co.uk/Blog/post/2009/09/18/A-RESTful-Wizard-Using-ASPNet-MVC-2e280a6-using-Data-Annotations.aspx
ASP.NET MVC is stateless, which means it doesn't save state between views like Webforms does.
You should save the information from each view into the database, and then set a flag in the user's database record at the end, indicating that the user confirmed their information.
If you need three separate views, you can always copy parts of the code created by the scaffolding to each of the three new views, using only those fields you want the user to see in each view.
If you need validation in each view, use a ViewModel object for each view that pertains only to those fields in the associated view.