Pros and cons of decoupling Umbraco
Following on from: http://www.wiliam.com.au/wiliam-blog/decoupling-umbraco-and-asp-net-mvc-5
For one of our clients, we had to decouple Umbraco to separate the front end and back end environments. This was quite a challenge but from early results it seems like a good approach.
There are a number of pros to doing this, mainly:
- It allows complete separation from frontend and backend websites. This means that you can do whatever you need to do on the frontend, and not need to worry about the technical limitations and pitfalls of what happens behind the scenes.
- The technical debt will be limited to the backend system. Since there isn’t a such thing as a bug-free CMS, it means that any bugs that are either currently in Umbraco or future bugs will most likely not affect the frontend UI.
- The frontend developers on the project won’t need to know Umbraco to work on it. Although all our developers here are proficient with Umbraco, if we were to get someone on board with the project for whatever reason, they can immediately start working on the UI logic without needing to understand the Umbraco framework whatsoever.
There are also a number of cons and pitfalls we’ve experienced as we have gone down this path:
- Most plugins will be utterly useless. A good example is the Infocaster 301 redirects plugin – whilst being fantastic at handling 301 redirects of all sorts, it is heavily tied to the front end to do the redirections. Since the frontend is separated, we needed to write custom code to handle the 301 redirect data that was saved on the backend and perform the redirections ourseleves. Whilst the task was easy enough to do, it set us back quite a bit.
- Not using the Umbraco framework means you need to start from scratch. Some of the essential modules we needed to build were:
- Our own XML read/write methods for the umbraco.config files. We created a few helper methods in order to achieve this – and there is a slight advantage in doing this as we are returning strongly typed models which is a lot better than dynamic objects.
We also wrote a file watcher that detected when the XML file changed from Umbraco, and subsequently refreshed the in-memory cache. It was neat but it took time. - An Umbraco route router. Since Umbraco uses a hierarchy to build its URLs, we needed to replicate this functionality through the frontend. This meant building a router which would process all of the URLs on the site individually and match them with attribute-decorated actions in our controllers.
This was in fact really nice to use in the end – this meant that we could organise all of our actions into logical controllers (e.g. Products controller with Category and Detail actions) and just decorate the actions with a doctype.
- Our own XML read/write methods for the umbraco.config files. We created a few helper methods in order to achieve this – and there is a slight advantage in doing this as we are returning strongly typed models which is a lot better than dynamic objects.
- No Umbraco helper methods. Say goodbye to UmbracoHelper, ContentService etc. if you wanted to utilise it from the frontend.
As you can see, there are a number of advantages (and hurdles) that we have faced when decoupling Umbraco. Personally I think that the advantages outweigh the disadvantages and long term, this is definitely a really good approach to work with!
