Best practice for migrating MVC web to Sitecore

Question

We have a couple of MVC 3.0 web application some of them combination of Web Form and MVC3.0 within on project/solution.

I'm quiet new to sitecore, could someone please help me understand following in regards to migrating the existing application to Sitecore?

1. On what type of scenarios should we move MVC3.0 razor views to sitecore?

2. What are the key gotchas migrating MVC3.0 to sitecore?

3. Do I need to inject anything on sitecore pipeline?

4. Do I need to change any of the navigation links to work under sitecore?

5. Any link to sitecore best practice for migrating existing web app will be good.

I followed the blog below and still unclear why and when should we convert web control and razor views to Sitecore Rendering.

Thank you.

Answer 1

When migrating MVC applications into a Sitecore solution you have a few options available - depending on the nature of the component you are migrating you would have to choose the most appropriate option.

I'll try and address your 5 specific questions:

1. When to use Razor views

I'm not sure if the question is "when to use a Razor view" or if the questions is "when to use Sitecore View Rendering" - I'll assume the latter.

A View Rendering is great if your are writing presentation components that do not require any business logic and only deals with rendering items. If you are contemplating adding code in your Razor view you should probably consider if a Controller Rendering would be more appropriate or perhaps customising the mvc.getModel pipeline.

2. Migration gotchas

Some of the things that may catch you out when migrating a MVC application to Sitecore.

• Component based controllers - in MVC you have one controller per page. Sitecore supports the concept of ControllerRenderings that allows you to have multiple controllers on a page (note: there will always be one route controller that can be perceived as the primary).
• Item routing - Sitecore has a catch all route that is effective for all paths that map to an item path. Standard MVC routes and "item routes" can happily coexist. Item routes do not currently support route parameters (e.g. you cannot specify {action} or other parameters on the item route).
• MVC4 - Currently no official support for MVC4 (this won't hold true for long - but in the meantime have a look at http://herskind.co.uk/blog/2012/10/sitecore-66-mvc4)
• Areas - Currently areas are not fully supported.
• Not knowing what rendering types to use and when to convert existing functionality into components.

3. Pipeline customisation

You are not compelled to customise the Sitecore pipelines. I can see a few examples where it would be useful to modify pipelines in the context of a migration story. One example I recently talked about at a Sitecore User Group involved adding a ActionFilter globally (through mvc.resultExecuting pipeline) that would inject a ASP.Net MVC application into a Sitecore place holder. In my example I injected the MVC Music Store into a placeholder and had Sitecore control window dressing (headers/footers/menus). This way I could bring my existing MVC application into Sitecore without having to change it much.

4. Navigation links

If your navigation endpoints are Sitecore item routes (e.i. the path to an item on the website) you should use Sitecore's LinkManager to generate the appropriate links. If the endpoints are standard MVC routes RouteLink and ActionLink should work just fine.

I guess without a concrete example the answer will be "maybe".

5. Best practice migration blog post

I'm not aware of any blog posts or articles dealing with Sitecore MVC migration best practice. Keep in mind that full MVC support is a recent addition to Sitecore and not many seen this journey from start to end yet.

Why and when to convert to Sitecore Rendering

You end your question stating that you are still confused about when and why you would convert controls and Razor views to Sitecore renderings. Here are some indicators that something is a candidate for being a Sitecore rendering:

• It is a component that can be reused on many pages.
• You want to enable Sitecore users to add the component to pages. (think Page Editor)
• You want to leverage Sitecore's component level caching.
• You want to leverage Sitecore security to restrict who can use/see the component.
• You want to control the component with personalisation, rules or run MVT on it.

In the context of MVC here are some indicators that it may not be right to convert something to a Sitecore rendering:

• It relies heavily on routing and route parameters.

I'm sure many of the points in this answer could be expanded on and I know that there are no clear cut rules for this - but I hope this answer helps clear up some of the confusion...