I've recently decided to try out MVC 2 and coming from a webforms background, I'm having a little trouble trying to figure out the best practice solution to caching data provided to a partial view (user control).
In my webforms application, I have an AccountSummary.aspx page, which has a Booking.ascx control. Booking.ascx had output caching of 300 seconds and in the Page_Load of AccountSummary.aspx, I used to check if the control was null, and if not, pass it a UserId. Then in the code-behind of the Booking.ascx, I used to make a data access call to fetch all the bookings, thus a call to fetch the bookings was made at most once every 300 seconds.
I would like to achieve the same in MVC2, but I can't seem to find the best way of achieving this because all the examples on the web seem to pass the data to the user control in the RenderPartial HTML helper method (which I don't want because on every page load I would have to pass the booking info which is going to kill my database!)
Please advise :-)
Cheers, A.
There is no simple mechanism for view-level caching in ASP.NET MVC 2.
There are some clever tricks to exploit the output caching in ASP.NET, like Donut Caching and Donut Hole Caching, but they both violate the MVC pattern (by making the DAL spill over into the views, for example), are very tricky to get right, and exhibit virtually undocumented behavior. (See the comments in the blog posts and other posts here on SO for more information.)
The short answer is that view-level caching (i.e. caching a partial view or a view, as opposed to an action method) is a trip you do not want to embark on if you are new to ASP.NET MVC. Hence, you should cache in your DAL instead, or on your action methods.
In your example, you could have a OutputCacheAttribute on an action method that returns a partial view with the booking list, or you could use the System.Web.Cache to cache the booking list when retrieving it in your DAL.
Related
This more of an out of interest question than an urgently need an answer one, but I have been trying to find a good example of how to deal with a full postback from a partial view in asp.net MVC. The obvious example is the case where you have a small login form on every page. You can easily accomplish this through an asynchronous post back using jquery, but I am wondering if there is a way to do it without the use of javascript. I know it may be pedantic, but I don't like the idea of assuming the client has javascript enabled, particularly in this day and age where responsive design/ progressive enhacements are the big buzzwords around, so having you log in tied to javascript means that anyone on a simple mobile device won't be able to use it since their device probably won't support it.
Anyone have any ideas / examples of how to accomplish this? It's such a simple thing to implement in web forms I can't believe it's as tricky as I've heard it made out to be in MVC.
You just need a form within the view, that's all. The form will POST to its controller action method and generate a full page refresh (if that's what you mean by a full postback - I guess it is) irrespective of whether its a partial or not.
You can have multiple forms on a MVC view, and each one of them will give you a full page refresh, whereas with WebForms the pattern was one main form per page.
I have a question about reuseable controls in ASP.NET MVC 3.
In our application we have a lot of tales on different pages. The tables have all the same logic, so we put a table in its own controller and view.
The data source and certain individual properties are submitted to the tablecontroller as parameter. The controller store the parameters in the tempdata to save them for self request by the tableview.
The table raises an AJAX request when sorting or paging, so that only parts of the table are updated. The request goes directly to the tablecontroller. The tablecontroller requires the parameters that we stored in the tempdata. So the table can call itself, without losing the data source and the properties.
My question is whether there is a better solution?
The current approach is not so nice, because the TempData are occupied with data to the end of the session. The pages and tables are linked and the user can switch between there. So its difficult to determine when certain parameters are no longer needed.
What is the best solution to build your own parameterized controls in MVC?
The right build your own parameterized controls in MVC in using Declarative Helpers.
However, this solution may be not flexible enough for asynchronous client-server interaction. For such interactive controls may be the best implementation is javascript template engine.
Is there a way to keep information between post backs in MVC2 without utilizing Session variables or the query string?
You mean like the view state from .NET Web Forms? Technically there is, although it isn't recommended - you're much better off utilizing models and posting the model data to the server and pushing the model back into the view.
This will work well but if you're needing something as stateful as the WebForms ViewState, I would recommend doing your project in WebForms or use the session to save your models.
Edit: Build your form that posts (or gets) data back to the same page. Then in your controller, have a method like this.
[HttpPost]
public ActionResult LoginUser(LoginViewModel model)
{
//work on the model here
return View(model);
}
This will push the form data that the user just submitted back into your view. Then have an Html helper like this in your view.
<%: Html.TextboxFor(m => Model.Username) %>
There are a slew of excellent resources on the web about using html helpers with models. Google around and you'll come across them.
You could use Hidden Form fields to POST the values back to the server with each form submission.
Other alternatives include a cookie or Http Cache - what is stopping you using session?
As a high level concept, you should rely as little as possible not only on Session to store your state, but on statefulness in general in a web application. The idea is that the web itself is stateless by design, and when designing software on that paradigm the software should be designed to embrace a stateless nature.
More specifically, using a ViewModel gives you a strongly typed representation of the data needed for your view to pass down to the client. Pieces of that data which hold information about the state of a given request which can be made from that view can be added to the view in probably a number of ways, but the two most immediate ones are:
As hidden form field elements
As parts of URLs for requests
Check out the NerdDinner tutorial for a standard approach to using either ViewData or a strongly-typed ViewModel. Some Google searches will, as always, yield more information and tutorials. But note specifically where the tutorial uses the ViewModel properties in the view. These can be used anywhere in the rendering of the HTML, either in the HTML helpers or in manually constructing the tags.
Additional interesting reading regarding the statelessness of the web (and this whole not-as-new-as-many-people-seem-to-think REST thing) is the article: How I Explained REST to My Wife.
If your main issue with the Session variables is of a practical nature (want something that works for a single request, not needing to worry about cleaning it up etc) rather than a requirement to not use Session then use the TempData dictionary. It deals with putting information in the Session for a single request only and the framework will automatically remove it for you afterwards.
I am currently considering the best way of building a relatively complex page in asp.net mvc. The page (and pages like it) will contain numerous 'controls' such as a shopping basket, recent news widget, login controls and more. In other words, it will be very component based.
My question is, what is the best way of building something like this in asp.net MVC? In regular webforms the answer would be simple thanks to user controls and the fact they can be nicely self contained. In MVC, I understand that in theory I should probably build a viewmodel that includes all the data needed for all my widgets and then render partial views in whatever page I'm building.
Could an alternative approach be to use javascript to load widgets 'dynamically' (think jQuery load) by simply calling into controllers that render partial views. That way I could have a basket controller, which when called renders out a basket. Of course, this relies on javascript....
Whats the best practise for situations like this?
Thanks
You could of course use JavaScript to populate the page sections but then this content will not be accessible to search engines (but that probably does not concern you).
What you need to understand that there is currently no way to make these partial views perform independently. Like talking to their own controller and posting data while having the rest of the stay unchanged (like it could have been done with WebForms and user controls). If you think postbacks and control state these things do not exist any longer. Your "control" makes a post, the controller has to process the request and then recreate the complete view along with all element values, states and other "user controls".
Unless you do it asynchronously with JavaScript of course. But then it's not gonna be an accessible page any more.
You can try SubControllers from MvcContrib or Steve Sanderson`s "Partial Request" approach.
But i warn you - communication between (partial requests, i haven't tried subcontrollers myself) them might get tricky and lead to mega failure. Use them only if you are completely sure that they are completely independent.
Anyway - that's a bad idea and should be avoided through controller/viewmodel inheritance or something....
My understanding of MVC is not yet up with WebForms, however is the generally accepted approach for stuff like this to simply throw these things in the ViewBag rather than include them in the ViewModel?
You could send down a main view model with some simple checks on it. Then render the appropriate Action if required. Then each partial could use it's own viewmodel and you wouldn't need to send everything down initially on the same viewmodel.
Razor:
#if (model.ShowShoppingCart)
{
#Html.Action("Index","ShoppingCart")
}
#if (model.blah)
{
#Html.Action("Index","blah")
}
I've started using MVC reccently, and one thing that occurs to me is whether its possible for the concept of a Control to exist in MVC?
From what I see the framework allows the application to be nicely factored into Models, Views and Controllers, but I can't think of a nice way to take a "vertical slice" of that application and reuse it in another application.
What I mean by that is it strikes me that any UI components I build with MVC maybe not very amenable to reuse, in the same way you can reuse a Contol in ASP.NET WebForms. Ok, there are HTML Helpers but I am thinking of something more modular. Something more like the control model in WPF.
Does this dichotomy go to the heart of MVC vs WebForms, or can reusable UI components work in an MVC world?
You can still use ascx files and other features in ASP.NET Web Forms. The only missing piece in MVC is the postback model and view state oriented state management. There is no <form runat="server"> anymore and no automatically generated hidden fields. Except these, all other features can be used in ASP.NET MVC. You can still write controls that post data using a REST based mechanism and use them in your views.
So, yes, as long as your controls don't rely on a server side form for postback, you can use them exactly the same way you'd use in ASP.NET Web Forms.
I was looking for the same thing - for reusable widgets with their own data paths and found this on Steve Sanderson's Blog:
http://blog.codeville.net/2008/10/14/partial-requests-in-aspnet-mvc/
From the article:
"You’ve heard of partial views, so how about partial requests? Within any MVC request, you can set up a collection of internal partial requests, each of which can set up its own internal partial requests and so on. Each partial request renders a plain old action method in any of your plain regular controllers, and each can produce an independent widget."
This article respectfully offers a alternative to The MVC Contrib Group's Sub Controller strategy (http://www.mvccontrib.org/) which is also a solution for what you are looking for.
I guess its harder in MVC to completely encapsulate rendering and post back handling in a single control you just drop on a page. It some ways this is because ASP.NET Webforms is very abstracted from HTTP semantics and that abstraction is a framework where its possible to create reusable user controls.
ASP.NET MVC doesn't have the abstraction of webforms so you can have a control the posts to three different controllers. While it may feel like your losing easy to use controls when you move to ASP.NET MVC, I think you have a better framework for separating and reusing domain logic.
In ASP.NET MVC you have partial views which can be reused. Rob Conery has a good post on this: ASP.NET MVC: Using UserControls Usefully
I think the closest thing you'll get to an old school controls are partial views, these are effectively just shared markup that you can drop on any page. However they don't have their own controllers out of the box so the code to power the shared UI component (the partial view) would need to exist in the controller of every page that used it. There are ways to reduce the duplication of code but without implementing partial view controllers and binding I don't think there is a way around it completely.