Develop Reference

ASP MVC - Pass model data or retrieve from database

I have a controller for my Portfolio, and the view model I am using is called DisplayItem. The function of the model is not relevant, but the models represent data about parts of my portfolio.
At the index page for this controller, the top 5 portfolio DisplayItems are built by pulling the required information from a database, and then a collection (List<>) is sent to the view. The view displays previews in a column with buttons to "view the project" for each project displayed. Clicking these buttons will route to the PortfolioController action "Display".
My question is about the efficiency of two methods of sending the appropriate data to the view for the action "Display". I can of course send the ID for the selected DisplayItem, and pull it from the database to rebuild the model and send it to the view. My initial thought was that this is unnecessary work for the database, seeing as I had previously pulled the required information. Though using the ID method would allow me to not pull the rest of the information until necessary.
My alternate idea is to serialize the model (it contains collections that can't be sent with POST), and then post what I need as a string to the action and then serialize into an object.
My experience is by and large not web, it is Game Programming, so I am out of my element to some degree and would love advice on which of the routes to opt for, or if there is some better way to do this.

I would prefer to query the database again whenever page loads. It allows to
-> check validation of input(id passed)
-> authorization of user for the requested info
-> decrease bandwidth(if data is large).
-> makes routing URL more user friendly(easy to bookmark).

As your application develops over time, your DisplayItem will have increasingly richer information pertaining to it, while your index view will only display summary information.
As the index view and the detail view will eventually require different sets of information, simply pass the ID field over the wire.
As Stepen Muecke says, reading from the database will be fast. Databases are good that way :-)

Better way to rebind a MVC model on POST using caching?

I have a controller with a get and post action, on the post it checks if the model state is valid. If it is valid the page process the data and redirect. If the model state is not valid it will return the view back with the model. To ensure the drop downs have data I need to repopulate the items from the database which means I need to make another call to the database.
Is there any way to cut the call out to the database by caching or any other method?

The problem is that the browser is only submitting the values for your drop downs and not the text. You could get around this by creating a hidden element which submits the text in addition to the values.
But is that a good idea? In my opinion, no. You're creating extra network traffic between browser and the server in order to save traffic between the server and the database. In most cases it will be more efficient to retrieve the data from the database than the client.
Also, the data may have changed between when you sent it to the client and when you send it back the second time.

Ryan has a good point. I'm assuming you're coming from a WebForms background where everything was cached in the view state and posted back to the server. Asp.net MVC by its very architectural lends itself to a different approach where it's standard to re-query the database for data presentation to the user i.e. dropdown list values.
So you should only post back to the server the values the user has input. This is happening via the view-model. I would make a common method which accepts your view model and does the standard database pull and map to model. This way you can use the same method for the initial Get request and also for validation failure post-backs.
Also, if we're talking about small data sets then I would most definitely re-query as it's not expensive to do. If the drop down lists are huge then it depends on the data itself. Does this data change infrequently? Then it might be feasible to cache it on the web-server in a static list. If it does change frequently then you could look into more advanced solutions like memcached or redis.

How do I use multiple user controls on an aspx page without making the same database calls in more than one control?

I'm currently on a project where each .aspx page is made up of multiple user controls (.ascx files). In some cases, more than one user control for a single page is making a call to the database for the same data. Two user controls might call the database for the same customer object to perform the tasks necessary to their individual circumstances. After all is said and done, some of the web pages end up making the same database calls 10 or more times because each user control needs the data for something it is doing. This does not seem efficient.
What are the best practices for handling this situation using ASP.NET Webforms? We have tried caching the database calls, but it just doesn't feel like a solid solution to the problem, although it has helped with performance. When using MVC, I can pass in a strongly-typed object containing all the data needed for a particular page, and the query for the data is only made one time. How do I achieve something similar using WebForms?

The best practices are the same as for any OO programming: Don't Repeat Yourself.
In this case, rather than having the user controls query the database to get their data, have the data passed to the controls, through properties. You can even use data binding, just like a "real" server control.
BTW, there's nothing at all preventing you from passing a strongly-typed object to the user controls, just like you would in MVC:
In MyControl.ascx.cs:
public MyControlModel Model {get; set;}
Then just have the calling page set Model before the control data binds.

Share Data Between Visual Web Parts on different pages

I have a need to share information from Web Parts on one page, with Web Parts on a second page. SharePoint does not have a default Session State, and let's say for arguments sake I cannot enable Session.
If there is a LOT of information, more than can be sent via Query String, is there another option?

Depending on the nature of the data that needs to be passed along, there are different ways to go about it. My first idea would probably be to save it in cookies on the active user. Another alternative is to save data to the property bag of the SPUser-object of the current user.
Really feels like a scenario to user Session-state though.. :)

MVC way of handling data input

I have a data input module where I add the information of my product and its sub information like:
product basic info
product price info
product price details
price info and price details are related to product and are lists
In my web forms approach I would store my main product object on the view state and I would populate it's pricing info and details while doing ajax postbacks. This way I can create a compact module that is very user friendly in terms of defining a lot of data from one place without the need to enter these data from seperate modules. And when I am done I would do one product.save() and that would persist all the data to the respective tables on db.
Now I am building similar app on .net mvc framework and pondering on what would be the good way of handling this on mvc.
I don't resonate towards storing all this on client side till I click save. And saving to the db after each action makes me remember the days I was coding on asp.
Will appreciate your inputs on ways to approach this on mvc framework

I believe the best way of doing this is storing the data on the client side. It reduces unnecessary postbacks and improves responsiveness of your application. If you really want to store it on the server, you can use SessionState.
If you really want to store it in something like ViewState, you can go with a solution like this: ASP.NET MVC - Is there a way to simulate a ViewState?. However, I recommend against it as it will make things more complicated. Doing it client-side is probably the most elegant way and storing it in SessionState is the easiest.
Remember that you can always escape the MVC pattern and use a simple Web form for that specific page (which will give you ViewState where you need it): ASP.NET MVC controller actions design

store your Product list to the Model of the view and each time you change a value you can do a Ajax post to the controller and save the changes to the db, use partial views to display each item in your product list

you can try to integrate http://www.castleproject.org/ActiveRecord/ for easy saving and updating. That way you can just map your Model on your database using ORM(Object Relational Mapping). It takes a bit more work in the beginning but you will end up with simple commands like product.Update() and product.Create()