【发布时间】:2015-04-04 00:00:24
【问题描述】:
我目前所在的公司正在为我们的应用范围做出架构决策而苦苦挣扎。目前我们有几个具有共同部分的应用程序(像日历模块一样思考)。到目前为止,我们一直在从其他现有应用程序中复制代码,但未来我们希望将我们的应用程序发展为更加模块化的设计:
如上图所示,每个应用程序可以有不同版本的模块。
我们正在考虑可能的解决方案:
- 构建一个核心应用程序框架,我们可以在其中安装我们的 模块。我们正在考虑使用像 Nuget 这样的工具来完成此任务。
- 构建一个包含我们所有模块的应用程序(=一个代码库),但客户只能获得为其激活的功能。我们在这里预见到版本控制存在一些问题。
对此有什么建议吗?我们不能成为第一个遇到这个问题的公司吗?我们所有的应用程序都是 ASP.NET MVC 4/5 Web 应用程序,使用 Razor 模板或 JavaScript 模板 (knockout.js) 构建。我们所有的应用程序都部署在 Microsoft Azure 上,并且我们拥有丰富的内部构建脚本 (MSBuild)、CI 服务器知识...
【问题讨论】:
-
我在以前的职位上工作过类似的设置。我们所做的是拥有一个包含所有项目的包罗万象的解决方案。应用程序的可重用元素将存在于每个 Web 应用程序引用的解决方案中的共享项目中。这没有解决的一件事是不同版本的模块,为什么会这样?我认为从长远来看,它只会让你头疼。至于每个客户端对不同模块的访问权限,这将由您的应用程序中的权限/安全结构控制。
-
您也可以将每个模块作为一个单独的项目,并将这些项目导入到每个更大的项目中。我更喜欢包含所有简单内容的大型解决方案,因为我讨厌通过大型树结构进行搜索。两者都达到了相同的结果。这也允许您保留旧版本的模块并将它们添加到更大的项目中/
-
@mattytommo 我们与付费客户合作。有可能我们想让某个客户(=应用程序)继续使用 1.x 版本,因为他希望这样,或者因为他没有为新版本 2.0 付费......
-
嗯,我明白了,但是技术上限制的功能可以在模块本身内管理。例如,如果您想在日历中添加提醒功能,您可以将该新功能在模块中仅限于您的付费客户。这正是我们在旧工作场所所做的。这就是我使用过的大多数应用程序管理此类内容的方式。
标签: c# asp.net-mvc knockout.js architecture modularity