我们有许多小型ASP.NET MVC应用程序。所有这些都基本上是一堆表格,它们捕获数据并将它们存储在SQL Server数据库中,通常这些表格会被加载到我们的数据仓库并用于报告。
我们希望重写所有小型应用程序,并为每个应用程序应用一致性和良好实践。所有应用程序都非常相似,我认为从用户的角度来看,如果它们似乎是同一个大型应用程序的一部分会更好,所以我们考虑将它们以某种方式合并在一起作为重写的一部分。
我们目前首选的两个选项似乎是:
创建一个单独的门户网站应用程序,它将成为应用程序的用户输入点。这可能在主页上有“贴图”,每个应用程序一个(将在此父应用程序中注册)并且可以将它们链接到所有应用程序。在这种情况下,所有应用程序将保留在不同的项目中并独立编译/部署。这似乎具有保持独立性的优势,因此我们可以对应用程序进行更改并进行部署而不会影响其他应用程序。我可以将常用代码拉入类库中吗?让我烦恼的一件事是,父应用程序必须基本上使用硬编码链接链接到每个应用程序。
我研究了在ASP.NET MVC中使用'areas',并将所有小应用程序作为一个大项目中的不同区域。这看起来很像更清洁,因为它们都在一个地方,但它的缺点是当任何一个单独的应用程序被更改时需要部署整个应用程序,我觉得我们会运行在添加了大量应用程序之后陷入困境。
我们有一个SharePoint安装,有人建议在SharePoint中创建门户类型应用程序......这对我来说听起来不是最好的主意,但我愿意考虑是否有人可以指出这种方法的优势。
对此架构有什么建议吗?有没有人在过去完成类似的项目,哪些方面运作良好/不好?
我们有4位开发人员,我们不希望应用程序在开发后更改太多(除了修复潜在的错误等)。但是,随着时间的推移,我们计划在解决方案中添加新的应用程序。
谢谢
答案 0 :(得分:0)
MVC区域的优势在于允许代码共享,通过重构每个应用程序的重复冗余部分来使用相同的基础架构代码(安全性,日志记录,数据访问等)。
但在最初合并代码时,这也意味着更多的冲突。
使用持续部署工具(市场上有许多工具)或部署到Azure WebApp可以减轻部署问题,然后部署插槽可以为您提供零停机时间部署。