We are building an ASP.NET MVC application which will be deployed behind a hardware load balancer that supports, among other things, caching.
Our proposal is to manually define which URL patterns should be cached by the load balancer. This will be quite an easy process for us as we have 'catalogue' pages which are relatively static, then 'order' pages which are not.
Must avoid using session state on cached pages, as the entire response is cached by the load balancer - this includes any cookies that are sent.
Ideally there would be an attribute which can be applied to controllers or action methods which allows selective use of session state, but there doesn't appear to be one. I realise that an approach like this would result in lost sessions if the use leaves the 'session zone' - that's fine.
Other than re-implementing the entire ASP.NET MVC HTTP controller... any suggestions?
Thanks in advance.
This is now moved from Futures into MVC3. There's a ControllerSessionState attribute (apparently will be named SessionState for the final release of MVC3), which can be applied to a controller, something like this:
[SessionState(SessionStateBehavior.Disabled)]
public class MyController : Controller
{
...
(But in the RC version, you must use ControllerSessionState
This is included in MVC 2 Futures. See http://blogs.msdn.com/rickandy/archive/2009/12/17/session-less-mvc-controller.aspx for more info.
Related
I am using the MvcSiteMapProvider Html Helper to create a navbar. The content of the navbar depends on the visitor rights therefore I am using security trimming to only display content which the person is authorized for. For performance improvement I am trying to cache this navbar.
The navbar is created in a partial view with the following content:
#Html.MvcSiteMap().Menu("MenuHelper", new { name = "MainMenu" })
Inside the layout file it is called by an action method which returns the partial view:
[System.Web.Mvc.OutputCache(Duration = 10, VaryByCustom = "User")]
[ChildActionOnly]
public ActionResult MainMenu()
{
return PartialView("MainMenu");
}
The caching of works fine at the root page of the sitemap. However when the cache duration runs out and the action method is called from deeper levels, no sitemap is returned.
When I disable security trimming or the output caching it works perfectly fine at all levels.
Is it possible that action method which returns the navbar, is called when the authorization data is unavailable and therefore returns a corrupt sitemap?
If you analyze the source for AuthorizeAttribute, you will note that it is not designed to work with child actions that are output cached (they go to some great lengths to ensure that child actions that are output cached will throw an exception).
Of course, it also won't work right if you have a custom AuthorizeAttribute that overrides OnAuthorization that does not duplicate this important logic.
However, there are a couple of things you can do to improve performance when using Security Trimming:
Make sure that your injection constructors are simple, especially on your controllers. If you have heavy processing in your constructors, it can really slow things down (with or without MvcSiteMapProvider, but Security Trimming makes this much more apparent).
If that doesn't improve things enough and you are not using a custom AuthorizeAttribute, you could use the roles attribute/property to duplicate your role logic into the SiteMap and remove the AuthorizeAttributeAclModule from your configuration (external DI only).
See this discussion for more details.
I'm looking at developing an application that will include a CMS. I'm a seasoned web forms developer but only really just moving into MVC.
I have a couple of questions that I hope some of you guys can answer:
First, my current web forms CMS allows users to create a page, and then "drop" any number of user controls onto that page they have created. The way I do this is to create an entry in the DB together with the path and then use the LoadControl method.
I can see I can do this with partial views, but partial views have no code behind. If I've potentially got 100 controls that people can drop onto a page, does this mean that the ViewBag in the controller needs to cater for all 100 controls just in case they are used on the view? For example, a web forms user control will contain logic: rptItems.DataSource = blah; rptItems.DataBind()
With MVC, I'm assuming that logic will be in the view controller and the view would access it by the ViewBag? I'm a little confused at how to do this.
Secondly, how would you handle deep routing?
EG:
Store/Products/Category is fine, but what about Store/Products/Category/Delivery/UK ? Would I need to set up a route in global.asax for each route I need? In web forms, I just called the ReWritePath method and handled the routing myself using regular expressions.
Thanks for the time to read this, and hopefully answer some of my queries
For your second question, (ie, "deep routing"), you can handle this within your controller instead of adding real routes. Each part of the url is available via the RouteData.Values collection inside of your controller action. So, your route may look like
~/Store/Products/Category/{*params}
Assuming typical route configuration, this would call the Category(...) action method on ~/areas/store/controllers/storeController, which could then grap delivery and uk from the RouteData.Values collection.
There are a lot of other approaches to this - storing routes in a database and using associated metadata to find the correct controller and method - but I think this is the simplest. Also, it may be obvious, but if you really only need two parameters beyond 'Category' in your example, you could just use
public ActionResult Category(string category, string region)
{
...
}
and a route:
~/store/{controller}/{action}/{category}/{region}/{*params}
Delivery and UK would be mapped to the the category and region parameters, respectively. Anything beyond uk would still be available via the RouteData.Values collection. This assumes that you don't have more specific routes, like
~/store/{controller}/{action}/{category}/{region}/{foo}/{bar}/{long_url}/{etc}
that would be a better match. ({*params} might conflict with the second route; you'll have to investigate to see if it's a problem.)
For your first question:
You can dynamically generate the view source and return it as a string from the controller, eliminating the need to pass a lot of stuff via ViewBag. If a virtual page from your CMS database requires inclusion of partial views, you would add the references to those components when generating the page. (This may or may not address your problem - if not, please provide more information.)
I created a simple ASP.NET MVC version 1.0 application. I have a ProductController which has one action Index. In the view, I created a corresponding Index.aspx under Product subfolder.
Then I referenced the Spark dll and created Index.spark under the same Product view folder. The Application_Start looks like
protected void Application_Start()
{
RegisterRoutes(RouteTable.Routes);
ViewEngines.Engines.Clear();
ViewEngines.Engines.Add(new Spark.Web.Mvc.SparkViewFactory());
ViewEngines.Engines.Add(new WebFormViewEngine());
}
My expectation is that since the Spark engine registers before default WebFormViewEngine, when browse the Index action in Product controller, the Spark engine should be used, and WebFormViewEngine should be used for all other urls.
However, the test shows that the Index action for Product controller also uses the WebFormViewEngine.
If I comment out the registration of WebFormViewEnginer (the last line in the code), I can see that the Index action is rendered by Spark engine and the rest urls generates an error (since the defualt engine is gone), it proves that all my Spark code is correct.
Now my question is how the view engine is resolved? Why the registration sequence does not take effect?
The order in which you register the view engines doesn't matter (much). Rather, view engines take a set of ViewLocationFormats, and if a particular view path fits the formatted name, that engine will be used. Only if you have conflicting formats does the registration order matter.
In the case of spark, views should have the .spark extension. WebFormViewEngine will respond to any with .aspx or .ascx extensions. And of course, as mentioned above, you can override any of this by changing the ViewLocationFormats supplied to the individual view engines.
Updated:
I took a look through the source of both SparkViewFactory and WebFormViewEngine (or more specifically, VirtualPathProviderViewEngine, which the latter derives from), and I can tell you why you're seeing this strange behaviour.
First of all, the Find method in the ViewEngineCollection class works like this (simplified):
foreach (IViewEngine engine in Items) {
// Query engine for cached view
}
foreach (IViewEngine engine in Items) {
// Query engine for uncached view
}
In other words, it will always try to find a cached view, in any engine, before resorting to uncached mode.
The way in which individual view engines implement this is the second overload of the FindView method, which takes a bool argument named useCache.
However, and here's where it all gets weird - the VirtualPathProviderViewEngine and SparkViewEngine have very different ideas of what the useCache argument means. There's too much code to repost here but the basic idea is:
The SparkViewFactory will look only in the cache if useCache is true. If it doesn't find anything, it automatically returns a "cache miss result" - i.e. nothing. On the other hand, if useCache is false, it will not look in the cache at all, it will skip the cache-checking step and go through the normal motions to resolve and create an actual view.
The VirtualPathProviderViewEngine, on the other hand, looks in the cache if useCache is true, and if it doesn't find the view in the cache, it goes off and creates a new one and adds that to the cache.
Both of these approaches work with respect to the way ViewEngineCollection performs its search.
In the case of spark, it "misses" on the first iteration of view engines, but "hits" on the second, and after that the view is added to the cache. No problem.
In the case of VirtualPathProviderViewEngine, it "misses" internally but returns a "hit" anyway on the first iteration, at which point the view is now cached.
So you should be able to see where the problem is here. The VirtualPathProviderViewEngine only appears to be taking precedence over the SparkViewEngine because the former always succeeds on the first (cached) iteration, but Spark only succeeds on the second (uncached) iteration.
In plain English, Spark really does get asked first, but replies: "No, I don't have that view yet. Try it without the cache instead." WebForms gets asked second, but automatically says "I didn't have that view, but I went and made one for you anyway, here it is.". And from that point on, the WebFormViewEngine always gets priority because it has the view cached and Spark doesn't.
Summary: Spark is getting priority, but due to a quirk in the way Spark treats the useCache argument, it's getting left in the dust when the Web Form engine is active at the same time. Either WebForm is over-eager or Spark is lazy, depending on your perspective.
Simply put, the solution is not to have conflicting views! If you've registered multiple view engines, then you should be treating any view name which can be handled by either/both of them as undefined behaviour.
Hmmm... Nope - all due respect webforms doesn't do anything beyond a cache-check when useCache is true. Same as Spark.
Actually - I think someone might have moved my cheese... Spark might have had a quirk added causing a false cache-miss during the useCache==true pass. If that's true it's more of a bug than different rules applied to that parameter.
Updated:
I was looking at MVC 2 originally - which is why I implied #Aaronaught's conclusions were incorrect. MVC 2 does not return a view on the first pass where useCache==true, which is different in MVC 1.0 which will resolve and populate.
So difference is between the way ASP.NET MVC 1.0 and ASP.NET MVC 2 are implemented. Spark and MVC 2 treat the useCache flag the same, and the order they are registered will give them priority.
We have a requirement to have our ASP.NET MVC websites be automatically closed down by a remote notification (change in database value). Where would be the best place to implement this?
Base Controller Class
Global.asax
Custom attribute
Other
Update
Lots of suggestions to use app_offline but this scenario will be happening daily and will be purely initiated by the database so I would rather have the application take the initiative rather than something external push the file in.
Also, I will probably need to redirect the users to a holding page (preferably an MVC controller method to keep everything consistent). I'm leaning more towards catching it in my BaseController and having that handle it
There's a standard way of "gracefully" terminating ASP.NET 2.0 webapp - just drop a App_Offline.htm to the root directory of your application. See this.
I would go with Global.asax Application_BeginRequest if you have to do it programmatically.
You could Response.Redirect the page to "Offline.aspx" which can retrieve a message from the database or whatever you need. Of course you'd have to look at the request to see if it was trying to get to "Offline.aspx" otherwise you'd end up in an infinite loop.
Or maybe all your applications can be redirected to a single website which would remove most the complication.
I'm going to answer this myself as I did it a different way but thanks to everyone for their responses.
What I ended up doing is overriding OnActionExecuting() in my BaseController class (which all my controllers derived from).
In this method I check the database (using a 1 minute cache) and if the website is closed I load up a view to display a closed message. Code shown below
Protected Overrides Sub OnActionExecuting(ByVal filterContext As System.Web.Mvc.ActionExecutingContext)
MyBase.OnActionExecuting(filterContext)
Dim _cfgService = ObjectFactory.GetInstance(Of IConfigService)()
If _cfgService.DynamicConfig.WebSiteClosed Then
filterContext.Result = ErrorHandler(_cfgService.DynamicConfig.WebSiteClosedTitle, _
_cfgService.DynamicConfig.WebSiteClosedMessage)
End If
End Sub
Handling this type of behavior in the Global.asax file sounds like the best solution and redirecting to a static "ofline/closed" page. Handle the request on the Application_BeginRequest method, check to see the the site is active, if it let it continue, if it is not online Response.Redirect the request to the static page.
protected void Application_BeginRequest(object sender, EventArgs e)
{
string redirectURL = "~/Offline.aspx"; //some static page
bool isOnline = false; //SQL Call, config value
if (!isOnline && !string.IsNullOrEmpty(redirectURL))
{
Response.RedirectLocation = redirectURL;
Response.End();
}
}
Sorry, don't know about ASP.NET, but in case helpful:
We have a single APPLICATION.ASP page for our site (CMS / Database merge type stuff); this is possibly not common and therefore may therefore restrict usefulness, but could perhaps be implemented by an INCLUDE at the top of all ASPX files
We rename APPLICATION.ASP to TEST.ASP and copy HOLDING_PAGE.ASP to APPLICATION.ASP
The HOLDING_PAGE.ASP is present in the WWW folder, so always ready-and-available. It contains a "Site not available" message etc. and is self contained for all CSS (no include files, no DB access). Only exception is the company logo (which is external to that file, obviously)
This method prevents all access to the site, is not dependant on having a working DB connection, and allows us to change anything on the site without interfering with the holding page (apart from Company Logo, but changing that is likely to be benign)
We can still access the site, internally, using TEST.ASP - so we can test any new rollout features before removing the holding page and putting the site live. If you want to prevent anonymous use of TEST.ASP then deny anonymous permission.
Remove holding page is: Delete APPLICATION.ASP (i.e. the holding page) and Rename TEST.ASP to APPLICATION.ASP
We also have a database flag that causes the normal APPLICATION.ASP page to show a holding page - which we can use whilst doing more minor changes.
I'm experimenting with MVC, and my question is - where I had Page_Load logic in Master Pages with WebForms, where should it go in MVC? Here's the business case:
Different Host Headers should cause different Page Titles to be displayed on the site's (one) Master Page, therefore all pages. For example, if the host header is hello.mydomain.com, the page title should be "Hello World" for all pages/views, while goodbye.mydomain.com should be "Goodbye World" for all pages/views.
If the host header is different than anything I have in the list, regardless of where in the application, it should redirect to /Error/NoHostHeader.
Previously, I'd put this in the MasterPage Load() event, and it looks like in MVC, I could do this either in every controller (doesn't feel right to have to call this functionality in every controller), or somewhere in Global.asax (seems too... global?).
Edit: I have gotten this to work successfully using the Global.asax method combined with a Controller for actually processing the data. Only problem at this point is, all of the host header information is in a database. I would normally store the "tenant" information if you will in a Session variable and only do a DB call when it's not there; is there a better way to do this?
There is no 1:1 equivalent in MVC for a reason, let's just recapitulate how to think about it the MVC way:
Model: "Pages of this site are always requested in a certain context, let's call it the tenant (or user, topic or whatever your sub domains represent). The domain model has a property representing the tenant of the current request."
View: "Render the page title depending on the tenant set in the model."
Controller: "Set the tenant in the model depending on the host header".
Keep in mind that what we want to avoid is mixing controller, view and business logic. Having controller logic in more then one place or a place, that is not called "controller" is not a problem, as long as it remains separated.
And now the good thing: You could do this "MVC style" even with Web Forms, and the solution still works with ASP.NET MVC!
You still have the request lifecycle (not the page lifecycle), so you could implement a custom HttpModule that contains this part of the controller logic for all requests. It handles the BeginRequest event, checks for the host header, and stores the tenant to something like HttpContext.Current.Items["tenant"]. (Of course you could have a static, typed wrapper for this dictionary entry.)
Then all your model objects (or a model base class, or whatever is appropriate for your solution) can access the HttpContext to provide access to this information like this:
public string Tenant
{
get { return HttpContext.Current.Items["tenant"]; }
}
Advantages:
You have separated cause (host header) and effect (rendering page title), improving maintainability and testability
Therefore you could easily add additional behavior to your domain model based on this state, like loading content from the database depending on the current tenant.
You could easily make more parts of the view depend on the tenant, like CSS file you include, a logo image etc.
You could later change the controller logic to set the tenant in the model not only based on the sub domain, but maybe based on a cookie, a referrer, search term, user agent's language, or whatever you can think about, without modifying any of your code depending on the model.
Update re your edit: I don't like the idea of holding the state in the session, especially if your session cookie might apply not only to each sub domain, but to all domains. In this case you might serve inconsistent content if users visted another sub domain before. Probably the information in the database that is mapping host headers to tenants won't change very often, so you can cache it and don't need a database lookup for every request.
You could create a base controller that supplied the correct ViewData to your MVC Master Page View, then derive each of your actual controllers from that one. If you put the logic into the ActionExecuting method, you should be able to generate an exception or redirect to an error page if necessary.
You are thinking too "WebForms" and not enough MVC. A master page is just a wrapper of your view, and it should only contain layout html. You can send stuff to your master, but it's a one way road and you should strive for agnostic views. Bottom line: forget about the events that WebForms had as they aren't going to be used here.
Since you are dealing with Host headers I suppose you could put it in the Global.asax...great now I'm confused :P
Stolen code from http://forums.asp.net/t/1226272.aspx
protected void Application_BeginRequest(object sender, EventArgs e)
{
string host = string.Empty;
if (this.Request.ServerVariables["HTTP_HOST"] == this.Request.Url.DnsSafeHost)
{
host = this.Request.Url.DnsSafeHost;
}
else
{
Regex regex = new Regex("http://[^/]*.host/([^/]*)(/.*)");
Match match = regex.Match(this.Request.Url.AbsoluteUri);
if (match.Success)
{
host = match.Groups[1].Value;
Context.RewritePath(match.Groups[2].Value);
}
}
// Match the host with the portal in the database
...
}
What you need is here http://www.asp.net/mvc/tutorials/passing-data-to-view-master-pages-cs