ASP.NET MVC -合并多个小应用程序
本文关键字:小应用程序 合并 NET MVC ASP | 更新日期: 2023-09-27 17:53:02
我们有一些小型ASP。. NET MVC应用程序。所有这些基本上都是一堆表单,它们捕获数据并将其存储在SQL Server数据库中,然后通常将其加载到我们的数据仓库并用于报告。
我们希望重写所有的小应用程序,并对每个应用程序应用一定程度的一致性和良好的实践。所有的应用程序都相当相似,我认为从用户的角度来看,如果它们看起来是同一个大型应用程序的一部分会更好,所以我们正在考虑以某种方式将它们合并在一起,作为重写的一部分。
我们目前首选的两个选项似乎是:
-
创建一个单独的门户应用程序,这将是用户进入应用程序的点。这可以在主页上设置"磁贴",每个应用对应一个磁贴(将在父应用中注册),并将它们链接到所有应用。在这种情况下,所有应用程序将保持在不同的项目中,并独立编译/部署。这似乎具有保持独立的优势,因此我们可以在不影响其他应用程序的情况下对应用程序进行更改和部署。我可以把公共代码拉到类库中?有一件事让我很恼火,那就是父应用基本上必须使用硬编码链接来链接到每个应用。
-
我研究了在ASP中使用"区域"。NET MVC,并将所有小应用程序作为一个大项目的不同区域。在我的脑海中,这似乎是一种清洁,因为它们都在一个地方,然而,它的缺点是,当任何单独的应用程序发生变化时,需要部署整个应用程序,我有一种感觉,我们将在添加一些应用程序到混合后遇到麻烦。
-
我们有一个SharePoint安装,有人建议在SharePoint中创建门户类型的应用程序…对我来说,这听起来不是最好的主意,但如果有人能指出这种方法的优点,我愿意考虑一下。
对于这个架构有什么建议吗?过去有没有人完成过类似的项目,有些项目运行得很好/不好?
我们有4个开发人员,我们不希望应用程序改变太多一旦开发(除了修复潜在的错误等)。但是,随着时间的推移,我们将计划在解决方案中添加新的应用程序。
谢谢
MVC area的优势是允许代码共享,通过重构每个应用的重复冗余部分,使用相同的基础架构代码(安全、日志、数据访问等)
但是这也意味着在最初合并代码的时候会有更多的冲突。
部署问题可以通过持续部署工具(市场上有很多)来缓解,或者如果您部署到Azure WebApp,那么部署槽可以为您提供零停机时间部署。