0

我目前正在重构一个庞大的单体 asp.net mvc 解决方案（作为网站/门户运行）并使用

  1. 通用业务逻辑（可用于创建类似门户）
  2. 核心业务逻辑（可用作领域逻辑）
  3. 公共存储库逻辑
  4. 核心存储库逻辑
  5. 门户特定的业务逻辑（如果通用业务逻辑不这样做）
  6. 门户特定的存储库逻辑（如果通用存储库逻辑不这样做）

如我所见，这种方法的问题在于在引入类似门户时，如果需要，我将不得不创建其特定的业务逻辑层和存储库逻辑层，这将增加解决方案中的项目数量（担心它会消失难以管理）

我如何在可管理的项目方面实现多门户解决方案？

4

1 回答 1

1

我遇到过类似的情况，有一堆 MVC 站点共享许多常见功能。

我们所做的是首先将所有这些常见的东西隔离在一个单独的解决方案中（我们称之为“全局”）。该解决方案的结构几乎与所有 MVC 站点相同，并且还包含“全局”特定的业务逻辑、接口、实体、存储库和 UI 组件（即：页眉和页脚、登录功能……）。这些常见功能被组织在可以部署的便携式区域中，只要您在一个 MVC 站点中需要其中一个，就可以使用专用的 Nuget 包。

为了能够测试我们开发的所有便携式区域，而无需部署它们，我们在 Global sln 中创建了一个“启动器”站点。从未部署此站点；它仅用于测试目的。

我们的 MVC 架构不是常见的 n-tiers 架构，而是Onion架构。如果您有兴趣，请查看所有相关的 StackOverflow 问题。我们所有的 MVC 站点都在使用 StructureMap DI，以便在启动时将我们使用的所有接口与正确的实现绑定。Global 有自己的 DI 容器配置部分。要使事情正常运行，您唯一需要做的就是在托管可移植区域的 MVC 站点的 Global.asax 文件中调用这两个方法：

GlobalConfig.Init();
GlobalConfig.RegisterAllAreas();

Init 方法是 StructureMap 将所有接口与正确实现绑定的地方，而 RegisterAllAreas 方法注册可移植区域路由和捆绑包。这两个方法必须在注册 MVC 站点自己的路由、捆绑包和 DI 东西之前调用。

这是全局 sln 文件夹结构：

全局 sln 文件夹结构

Web.xxxx 项目是您需要创建的所有不同的可移植区域。即使您的 MVC 站点只需要用户帐户共享功能，最好将事物分开以避免始终需要部署所有内容。

下面仔细看看其中一个 Web.xxxx 项目结构：

Web.xxxx 项目结构

可移植区域项目名为 xxxx.Area，它包含该区域的所有视图和控制器。它还有 xxxxAreaRegistration.cs，它定义了该区域的路线和捆绑包。

视图模型和构建器位于名为 xxxx.ViewModel 的单独项目中。

xxxx.Domain 和 xxxx.DomainModel 项目是存储该区域的所有服务实现和域模型的地方。Xxxx.Data 是该区域的存储库实现所在的位置。

所有区域服务和存储库接口都存储在 Contract 项目中（见图#1），并且可以使用特定的 Nuget 包单独部署。

这是我们在这里组织事物的方式的大图，如果您想使用这种架构，如果您需要更多信息和细节，请不要犹豫。

希望有帮助！

于 2013-05-06T09:15:32.347 回答