I have a DropDownList that particpates in an Address View Model.
Is it best to store the list of 170 or so countries in a database and load them into a collection on the View Model, or is it better to hard code them into the View Model as a collection containing SelectListItems?
Which is best practice?
When does hardcoding SelectListItems become too many as most people would choose to hardcode the title of a name: Mr, Miss, Ms, and Mrs....
I would definitely advise putting them in a database.
ASP.Net MVC has some nice caching features so using those you won't be making a live call to your database for every user that hits that page.
So since the data call can be cached there is no real downside to putting them in the database but quite a few upsides.
Related
I'm creating a web app for my client as a part of my schools final project.
It's a web app where users fill forms (surveys) and after forms are submitted,
values are saved in the database.
There are three types of users: admins, moderators and viewers. Admin's can see the
overview of filled forms, moderators will fill these forms and they also can make edits
to them and get the overview of the forms they've filled. We haven't discussed about the rights of viewers
at this point.
I'm using CodeIgniter as a framework of my project since it comes pretty handy when it comes to database
manipulation and forms. What would be the best way to implement this kind of situation? There are apprx.
4-5 forms (surveys) each moderator will fill. After they've filled them, they only can make edits to that particular form.
So one user can fill each form only once.
I've designed that each of the forms needs one table. So if there is a form (survey) about IT equipment, I will create
a table for IT equipment. User's id number will be saved in to the last column in the table, usually called "user_ID" where I can
make queries based on users and check if user is already filled the particular form.
What about controllers and models? I've thought I could only make one model for inserting and editing the form.
However, is it pretty much the only way to create a controller or method foreach form since there are different types
of form fields to validate based on the form user is actually filling. I've already created a controller for inserting and updating
the IT equipment form and both of these methods are pretty big when it comes to the amount of code, over 200 lines per method.
So that would be a total amount of 2000 lines of code just for inserting and editing all the forms.
What'd you do and how you'd implement this if dealing with similiar kind of project?
Thanks in advance for all the ideas and point of views!
You should take a look into this:
http://cibonfire.com/
It's a really good addon for codeigniter, that allows you to data oriented development.
Am new to ASP.NET MVC 3.0. Request expert's view on the below mentioned scenario.
I have a customer details page, where only Name is editable. There are 10 other customer properties that are non editable and displayed using SPAN. When user submits the page, I need to update only the Name.
If am using EF, I will have to load customer again, overwrite name and then save. Otherwise I will have to maintain customer model somewhere.
Anyone tried caching model (or viewmodel) using session id? Is it a good practice?
You are almost thinking in right direction.
If am using EF, I will have to load customer again, overwrite name and then save. Otherwise I will have to maintain customer model somewhere.
In Update Method **Load Customer again and update name Only as required and then save
**For 2 reasons
The first and most important rule is 'don't trust user data'. and
Concurrency and to avoid saving old data. See this example
Instead of using Session, I will suggest to use Hidden Field for record LastUpdateDateTime and Customer ID which will be posted back in the model to retrieve record and verify LastUpdatedtime with database record
Tipically, you should use a view model different than the database model. Having said that,in your current case the situation is very simple, submit only the name to the controller and then set the Name property of the object you get from EF with the submitted name.
Caching the view model or the model isn't your concern. The database model caching is handled by EF, your problem is mainly a lack of clear application layering. IN fact I strongly suggest to learn a bit more about the MVC pattern, basic application architecture (2-3 layering) and when and how to use a OR\M (which EF is).
use hidden inputs for other properties in your form. In that way you can get all properties binded to your EF entity and you dont need to get entity again from db.
#Html.DisplayFor(model=>model.x)
#Html.HiddenFor(model=>model.x)
or you can serialize the entity(if you use POCO entities) and set to hidden input. When you post back you should deserialize the entity.
My choice is always first one. :)
I have programmed in Rails, Django, Zend, and CakePHP. Also, Wordpress and Drupal.
Now, I am "catching up to speed" in as fairly large application in CodeIgniter.
Typically, my experience with MVC frameworks, has led me to believe that Models represent business logic in reference to actual database tables. In the CodeIgniter docs and in the code base I'm dissecting I see models created that represent something as vague as a page. A lot of the business logic is written directly into those models and they incorporate other actual data models. I'm not sure this is ideal and following MVC.
Should models be created beyond data models?
Also, lets say I have a data model representing a user (user table in DB). In that user table there is a column called gender of the type enum('male', 'female'). Now I want to populate a dropdown with the gender options from the enum column.
Where is it most appropriate to put this logic?
The user model is an object used to represent a single user or row in the db... right? So it doesn't seem fitting to include a function in the user model/class called "get_gender_options", because, while the function is related to the user table, it is NOT relevant to a single user object. In Zend this kind of logic could be built into the form object itself.
There is not "right" answer, just one we can consider the most appropriate...
I would probably just put the "get_gender_options" in the model, rather than sticking it in the view for the form. To keep it DRY but not put it in the model, I would create a helper to hold this.
I have a web application built on an MVC design.
I have a database which contains a large number of objects (forum threads) which I can't load into memory at once. I now want to display (part of) this collection with different filters in effect (kinda like what stackoverflow does with questions sorted by date, votes, tags etc).
Where do I implement the filtering logic? It seems to me that this must go into the model part of the application, as only models interact with the database (in my implementation). If I make the filtering a part of the view, then the view must access the database directly to get the list of filtered objects, right? I'd like to avoid this, because it exposes the database layout to the view. But at the same time, displaying different views of the same data should be implemented in the view part of the application, as they are just that -- different views of the same data.
So how do I resolve this? Do I create an additional model, say, FilteredThreadsList, and have it remember the filter to use, and then use a FilteredView to display the list of threads that FilteredThreadsList spits out?
Or do I have to build a ThreadQueryier that allows views to query the database for certain thread objects, so I can have the filtering logic in a view without exposing the database backend?
You should never query data from the view. I don't know what framework you are using in particular but as for Ruby on Rails (should be the same for other frameworks) we always pull the necessary data from the controller and store all that information into a variable. The variable will be accessed by the view which can help you avoid querying your database directly from the view.If the code to query the database gets too lengthy in the controller, insert that code into the model instead so it's more maintainable for your project in the future. Additionally, you can call this model method from multiple places in your application if needed. Good luck!
From an architectural point of view, the model should be having the code for filtering. This is so, because in many applications the code for filtering is not trivial and has a good amount of domain logic in it. (Think of filtering top gainers from a list of stocks). From your example as well, it looks the same since you might want to filter by vote or by date or by tags and then by answered or unanswered etc.
In some very simple applications that deal with search/list of entities and allows Create/Read/Update/Delete of an entity, the pagination, sorting and filtering logic is usually very generic and can be implemented in a controller base class that is inherited by all entity-specific controller classes.
The bottom line is this: if your filtering logic is generic put it in the controller else put it in the model.
Model, that's only bunch of entities.
View provides a visual representation of the data from model - use as much of views as you want. If your application is web based, you can fetch data into browser just once (AJAX) using and re-use them for different UI components rendered in the browser.
As for what entities and what view to use for their representation, I think it's work of Controller. If you need some support for it on "model layer", add it but avoid tight coupling.
I can't quite decide how to go about separating my view models from my DB models.
I'm using an ActiveRecord pattern for my DB access. Meaning I get a User class instance for each User row in the database.
In WebForms I'm used to use these as my model objects, implementing most of the business logic directly on my ActiveRecords.
I realize this isn't exactly 3-tiered design, and I'd really like to improve upon it, especially in MVC, where separation of concerns is empathized.
So I'd think the Controller shouldn't have access to my DB models, but how do I then go about storing/loading data from the DB ?
It's not my impression you should place a huge amount of business logic in your view models either, so somehow I think I'm missing a central piece of the puzzle.
What I'm looking for is some best-practice advice I guess :-)
I hope all this made sense, otherwise please ask.
I strongly suggest creating one view model per view and using AutoMapper to map properties from your active records to your view models. I don't believe that there's a problem with your controller having access to your DB models; the controller should be responsible for translating them into view models.
As for translating view models (really post data models) back into active records, you can use AutoMapper for this as well in simple cases and custom code for the rest.