I was wondering what is the best practice or recommended way to develop an Umbraco MVC website.
So far I have come across the following:
1) Umbraco back-office is used to create document types, related templates and from there, the actual content pages. This is depicted in the official Umbraco tutorial. No specific controllers are created in this approach but only Umbraco fields eg: @Umbraco.Field("title", recursive: true). To me the document types seem to be the Model, the templates the View and Umbraco magically (I'm sure there is a valid explanation :-)) manages the Controller.
2) The other approach I have seen is that document types and templates are created via the Umbraco back-office (like mentioned above) but repository and custom Model/ViewModel classes are added (via code) for each page and the UmbracoHelper class is used within the repository classes to extract data from Umbraco, populate the models and bind them to the views. Obviously, this requires creating controllers that inherit from RenderMvcController.
I was wondering which of the above approaches are industry standards or best practices that developers use.
Alternatively, if you know of another approach, I'd be happy to hear about it.
The approach in building a site is really dependant on what functionality is contained within the site.
So for brochure type sites there is very little need to create controllers as in point 1, Umbraco magically handles the controller part of MVC, and all you need to do is create the document types, views and partials to build the site.
Having said that most sites have a contact form, and so as you are requiring server interaction, you then need associated controller actions, etc.
It is quite amazing that for an MVC site, you need to write very little server side controller code due to how Umbraco manages the content on your behalf. It is then simply down to functionality requirements that determine the level of controller interaction.
I can just back up what Nigel has said, there are a few things I'd also point out however:
By using Models Builder and property value converters which are both now part of Umbraco core, the heavy lifting is done for you. Models Builder automatically generates models for you and property value converters change the properties into types that make sense i.e. a content picker will return the actual content (IPublishedContent). This keeps your project and views really tidy.
Whether you then need to introduce render controllers is a decision I'd usually make per document type. Is there some kind of extra logic you need above what the models builder provides? Then set up a render controller for that document type/template. I wouldn't suggest a controller for every template because, again, Umbraco does it's magic in the background.
Beyond setting up document types and templates, you'd also probably want to look into Surface Controllers, I tend to use these when I'm rendering something into a page, that needs some kind of logic in the background but isn't reliant on the document type. For example, I might want to render a navigation menu that displays links to sibling content. The surface controller would go away and get those links, put them in a custom model and then send them back to where the call was made to render the menu.
Best practices with MVC using Umbraco
Hi All,
I was wondering what is the best practice or recommended way to develop an Umbraco MVC website.
So far I have come across the following:
1) Umbraco back-office is used to create document types, related templates and from there, the actual content pages. This is depicted in the official Umbraco tutorial. No specific controllers are created in this approach but only Umbraco fields eg: @Umbraco.Field("title", recursive: true). To me the document types seem to be the Model, the templates the View and Umbraco magically (I'm sure there is a valid explanation :-)) manages the Controller.
2) The other approach I have seen is that document types and templates are created via the Umbraco back-office (like mentioned above) but repository and custom Model/ViewModel classes are added (via code) for each page and the UmbracoHelper class is used within the repository classes to extract data from Umbraco, populate the models and bind them to the views. Obviously, this requires creating controllers that inherit from RenderMvcController.
I was wondering which of the above approaches are industry standards or best practices that developers use.
Alternatively, if you know of another approach, I'd be happy to hear about it.
Thanks Noel
Hi Noel
The approach in building a site is really dependant on what functionality is contained within the site.
So for brochure type sites there is very little need to create controllers as in point 1, Umbraco magically handles the controller part of MVC, and all you need to do is create the document types, views and partials to build the site.
Having said that most sites have a contact form, and so as you are requiring server interaction, you then need associated controller actions, etc.
It is quite amazing that for an MVC site, you need to write very little server side controller code due to how Umbraco manages the content on your behalf. It is then simply down to functionality requirements that determine the level of controller interaction.
Hope that helps
Nigel
Hi Noel,
I can just back up what Nigel has said, there are a few things I'd also point out however:
By using Models Builder and property value converters which are both now part of Umbraco core, the heavy lifting is done for you. Models Builder automatically generates models for you and property value converters change the properties into types that make sense i.e. a content picker will return the actual content (
IPublishedContent). This keeps your project and views really tidy.Whether you then need to introduce render controllers is a decision I'd usually make per document type. Is there some kind of extra logic you need above what the models builder provides? Then set up a render controller for that document type/template. I wouldn't suggest a controller for every template because, again, Umbraco does it's magic in the background.
Beyond setting up document types and templates, you'd also probably want to look into Surface Controllers, I tend to use these when I'm rendering something into a page, that needs some kind of logic in the background but isn't reliant on the document type. For example, I might want to render a navigation menu that displays links to sibling content. The surface controller would go away and get those links, put them in a custom model and then send them back to where the call was made to render the menu.
Hope that makes some kind of sense,
Ben
is working on a reply...