The slides from my presentation about Sitecore MVC during the Sitecore Technical User Group on the 19th of April in London, United Kingdom.

1. Sitecore MVC
How to implement Sitecore using MVC Presented by Ruud van Falier

2. Topics
 The basic concept of (Sitecore) MVC
 Sitecore renderings related to MVC
 Views
 Models
 Controllers
 Inversion of Control
 Dependency Injection
 MVC vs. WebForms
 Need input: named parameters / URL routing

3. The basic concept of MVC
How we used to roll…

5. The basic concept of MVC
View
Model
Controller
User
Uses
Manipulates
Updates
Sees

6. The basic concept of MVC
Views display a certain set of data.
They do not know where the data comes from.
Models are classes that hold data.
They may also execute logic for managing this data.
They do not know how the data is displayed.
Controllers are classes that execute logic that controls
what data is seen and which view is used to display it.

7. The basic concept of MVC
Browser URL Routing Controller Model View
Request
Invoke action
Initialize
Lookup view
Render
HTML
An ASP.NET MVC request

8. The basic concept of MVC
A Sitecore MVC request
Source: Martina Welander
Request
httpBeginRequest
pipeline
MVC
route?
Layout
specified?
Is it an MVC
view file?
Controller
specified?
MVC
request
WebForms
request
No No No
No
Yes Yes Yes
Yes

9. VIEWS

11. Source: Phil Haack

12. Views
Do
 Display data from a model
 Use simple flow logic that is
required to present data (if /
foreach / retrieval methods)
Don’t
 Add complex logic
 Go nuts with inline code

13. Sitecore renderings related to MVC
 View Rendering
Renders a View using a built-in controller action.
The controller passes a model of type RenderingModel to the View.
 Controller Rendering
Calls an action on a controller and lets the controller handle the View rendering.

14. Can you demo that?!

15. MODELS

16. Models
public class ContentPageModel
{
public string Title { get; set; }
public string Intro { get; set; }
public string Body { get; set; }
}
public class ContentPageModel
{
public string Title { get; set; }
public string Intro { get; set; }
public string Body { get; set; }
public ContentPageModel Parent { get; set; }
public IEnumerable<ContentPageModel> SubPages { get; set; }
}
public class ContentPageModel
{
/* Snipped properties */
public void CreateSubPage(ContentPageModel model)
{
// Logic for creating a sub page.
}
public void DeleteSubPage(ContentPageModel model)
{
// Logic for deleting a sub page.
}
}

17. Models
Do
 Hold data
 Provide logic to manipulate
data
Don’t
 Add presentation elements to
data
 Use for application logic

18. CONTROLLERS

19. Controllers
PageController
About
Portfolio
News
Request
/page/news
var model = repository.GetNews();
return View(model);
/Views/News.cshtml

20. Controllers
Do
 Retrieve data required to
initialize models
 Initialize models
 Return appropriate View (or
other ActionResult)
Don’t
 Cramp them with logic
 Use them if it’s not necessary

21. Inversion of Control
“A software architecture with this design inverts control as compared
to traditional procedural programming: in traditional programming, the
custom code that expresses the purpose of the program calls into reusable libraries
to take care of generic tasks, but with inversion of control, it is the reusable code
that calls into the custom, or problem-specific, code.”, Wikipedia
The decoupling of dependencies by isolating code for certain
responsibilities into separate libraries and referring to those libraries
using their interfaces instead of their concrete implementation.

22. Inversion of Control
Inversion of control serves the following design purposes:
 To decouple the execution of a task from implementation.
 To focus a module on the task it is designed for.
 To free modules from assumptions about how other systems do
what they do and instead rely on contracts.
 To prevent side effects when replacing a module.

23. public class MvcDemoController : Controller
{
public ViewResult NewsOverview()
{
// Get news root item from Sitecore.
Item newsRoot = Sitecore.Context.Database.GetItem("{NEWS-ROOT-GUID}");
IEnumerable<Item> newsItems = newsRoot.Children;
// Get temperature from weather service.
var weatherService = new WeatherService();
int temperature = weatherService.GetTemperature();
// Initialize model for News Overview page.
return this.View(new NewsOverviewModel
{
NewsItems = newsItems,
Temperature = temperature
});
}
}
TIGHT COUPLING

24. public class MvcDemoController : Controller
{
private readonly ISitecoreContext sitecoreContext;
private readonly IWeatherService weatherService;
public MvcDemoController(ISitecoreContext sitecoreContext, IWeatherService weatherService)
{
this.sitecoreContext = sitecoreContext;
this.weatherService = weatherService;
}
public ViewResult NewsOverview()
{
// Get news root item from Sitecore.
Item newsRoot = this.sitecoreContext.ItemManager.GetItem("{NEWS-ROOT-GUID}");
IEnumerable<Item> newsItems = newsRoot.Children;
// Get temperature from weather service.
int temperature = this.weatherService.GetTemperature();
// Initialize model for News Overview page.
return this.View(new NewsOverviewModel
{
NewsItems = newsItems,
Temperature = temperature
});
}
}
LOOSE COUPLING

25. Dependecy Injection
There are several methods for Dependency Injection, some examples are:
 Constructor injection (as seen in the example)
 Parameter injection
 Setter injection
 .. and more
Use a framework that handles Dependency Injection for you
• Windsor container (because it ships with Glass)
• Ninject
• Autofac (TODO: Check)

26. public class MvcDemoController : Controller
{
private readonly ISitecoreContext sitecoreContext;
private readonly IWeatherService weatherService;
public MvcDemoController()
: this(new SitecoreContext(), new WeatherService())
{
}
public MvcDemoController(ISitecoreContext sitecoreContext, IWeatherService weatherService)
{
this.sitecoreContext = sitecoreContext;
this.weatherService = weatherService;
}
}

27. OH MY GOD, THAT’S SO NOT FAIR!
MVC vs. WebForms ?!

28. MVC vs. WebForms
Why MVC is better
• Simpler page lifecycle.
• No more server controls.
• Multiple forms on a page.
• No more ViewState.
• Very easy to work with AJAX.
• Not bound to generated markup.
WebForms is just an extremely complex abstraction
over HTML/JS, made up before the birth of jQuery and
AJAX; we don’t need this abstraction anymore.
Let me know if you need more reasons 
When to stick to WebForms
• Legacy application
• Team knowledge
• Prototyping

29. References
 Follow me on Twitter: @BrruuD
 Contact me by e-mail: ruud@partechit.nl
 Read our blog: www.partechit.nl/blog
This presentation will become available online after the
Sitecore User Group Conference on the 23rd of May in Utrecht, The Netherlands.
More info and tickets: www.sugnl.net