Backoffice and Frontoffice to separate projects

Question

I'm building a project using mvc framework.

I'm at a point where i need to decide if I should separate frontend and backoffice to two mvc applications

This is to make my solution tidy and well structured. But at the same time I don't want to increase maintenance on the long run. Can you please share with me your experience on the long term when application becomes quite large, if it is better to have two seperate projects or just have a Backoffice folder under the main web project.

Another concern that I am realizing is how do I handle images between these two projects.. User uploads photos from backoffice to a folder that reside under backoffice application then how do I display these photos through frontend or vice versa..

Thanks

Answer 1

One way to think about this is to ask "Are the fundamental actions and desires of the users different". Then ask, "What's the scale of the back office site". The larger, the more likely I'd split it. If it was just a handful of admin pages or a couple reports, I'd live with it in the original project. In addition, "Do the front and back offices need to scale at different rates?" 1 million hits / hour vs 20 fulfillment staff to make numbers up out of no where. And thirdly, "Do the front and back office customers live in different security domains" Being able to deploy the back office code behind the firewall would make it a tocuh safer.

There is overhead for the developer, but sometimes that's okay if you get clarity, security, or simplicity.

A suggestion, assuming you want to split it, split into three projects: Two web front ends and a library that holds shared code and resources, like some basic database access code. Actually, three may be two few projects if you want to share helpers, etc.

Answer 2

I'm a huge fan of separating the apps as the advantages tend to outweigh the advantages in most cases. Ball points out a number of the big points, mainly revolving around the different use cases and security contexts. The other big kickers for me are:

a) You can get moving on the back office stuff while some of the front-end details are still up for discussion. IE--you are not blocked by marketing being all wishy/washy about what template and color scheme to use.

b) You can make different technology choices depending on app. EG, your back office could use traditional ASP.NET webforms because you are not concerned with SEO and other webby behavior as well as can guarantee what browsers and bandwidth capabilities you will have to deal with.

Overhead-wise, there really isn't too much additional work IMHO. And most of those problems are pretty solvable. For example, your images issue could be handled by either storing the images in a database or making a common file store that both apps could reference.