Question

I’m accustomed to structuring my CMS and client sites in two different areas of a single MVC project. This MVC project references an application layer (class library) that services both areas within that MVC project. The application layer references a domain layer which then references a data layer (both in their own separate class libraries). The MVC application only knows of the application layer.

I’m starting to desire the benefits of seperating the CMS into it’s own application, some of which are:

1. Getting quite a large CMS presentation code base out of a client project that is often very lightweight.
2. Not having to rebuild the same CMS code base when there is no custom functionality for a particular client (the CMS often doesn’t need to be altered for a new client)
3. Being able to upgrade the CMS in production with no worries about affecting the web site (vice versa)

In order to do this, from my initial research I’ve found that I would need to create a WCF application that would reference the application layer. Then from here, the CMS MVC application and the Client MVC application would only communicate with the WCF layer.

Downfalls of this approach:

1. Require 3 individual applications available in the hosting environment.
2. Overhead of messaging between the different applications.

Is this easiest approach to achieve what I want? Can anybody throw me some examples or easy to understand case studies of similar situations?

Answer 1

I’ve seperated the CMS out into it’s own project but following the same namespace. Now I can just reference the cms dll from my client MVC application, set up the route and copy over the file assets (views, content).

As for the WCF layer, I’ve decided to hang out for the Web API in MVC 4 and make do with that until I stretch the limits of it and have to move to WCF.