Backoffice和Frontoffice分离项目

Question

我正在使用mvc框架构建一个项目。

我需要决定是否应该将前端和后台分离到两个mvc应用程序

这是为了使我的解决方案整洁和结构良好。但同时，我也不想增加长期的维护。你能与我分享你的长期经验，当应用程序变得相当大，如果它是更好的有两个独立的项目或只有一个Backoffice文件夹下的主要网络项目。

我意识到的另一个问题是如何处理这两个项目之间的图像。用户将照片从后台上传到位于后台应用程序下的文件夹，那么我如何通过前端显示这些照片，反之亦然。

谢谢

Answer 1

思考这个问题的一种方法是问“用户的基本行为和愿望是否不同”。然后问，“后台网站的规模有多大”。越大，我就越有可能拆分它。如果只是几个管理页面或几个报告，我会在最初的项目中接受它。此外，“前台和后台需要以不同的速度扩展吗？”每小时100万次点击与20名执行人员相比，无中生有地创造了数字。第三，“前台和后台客户是否生活在不同的安全域”能够在防火墙后面部署后台代码将使tocuh更安全。

这对开发人员来说是有开销的，但有时如果您获得了清晰度、安全性或简单性，这是可以接受的。

一个建议，假设你想拆分它，拆分成三个项目:两个web前端和一个包含共享代码和资源的库，就像一些基本的数据库访问代码一样。实际上，如果你想共享助手，三个可能是两个很少的项目，等等。

Answer 2

我是分离应用程序的铁杆粉丝，因为在大多数情况下，优势往往大于优势。Ball指出了许多要点，主要围绕不同的用例和安全上下文。其他对我来说最重要的是：

a)在一些前端细节仍有待讨论的情况下，您可以着手处理后台工作。IE--你不会被市场营销所阻碍，不知道该使用什么模板和配色方案。

b)您可以根据应用程序进行不同的技术选择。例如，你的后台可以使用传统的webforms，因为你不关心搜索引擎优化和其他ASP.NET行为，以及可以保证什么浏览器和带宽能力，你将不得不处理。

就开销而言，确实没有太多额外的工作。这些问题中的大多数都是可以解决的。例如，您的图像问题可以通过将图像存储在数据库中或创建两个应用程序都可以引用的公共文件存储来处理。