c# - 需要大规模 .Net MVC 项目的架构建议

Question

我会尝试尽可能详细地解释。这里可能有类似的问题，我已经完成了所有这些问题，但没有一个有我需要的。

因此，我从一个基于C# MVC5的大型 Web 项目开始，我希望以尽可能解耦的方式组织所有内容。对于数据库部分，我将使用 Telerik 的数据访问 ORM(以前称为开放访问)，因为我将在我的项目中使用 MySQL。

到目前为止，我已将所有内容组织如下。我定义了解决方案级别文件夹来划分项目，因为我认为将来可能会在一层中包含更多项目。

**Solution**: td
- Business (Folder)
-- td.core (Project) (Contains Services and ViewModels)
-- td.interfaces (Project)
- Data (Folder)
-- td.data (Project) (Contains Database Models i.e. Telerik, Repository, Context Factory and Unit of Work class)
- Presentation (Folder)
-- td.ui (Project) (MVC5 Project, also Implemented IoC here)
- Shared (Folder)
-- td.common (Project)

一般来说，当您在 MVC 项目中绑定(bind)模型时，如果您的解决方案中只有一个项目，那么它会很轻松地工作，不会出现任何问题。

即在 MVC Controller 中

var obj = new TempClass();
return View(obj.getAllUsers());

然后在相应的 View 中在顶部使用它

@model(此处为模型类型)

当我如上所述将所有这些层分离到他们自己的项目中时。数据层将是直接与数据库通信的层，因此我将在数据节点中生成 Telerik Data Access rlinq 架构，其中还将生成数据库中表的类(默认配置)

现在，根据上面的设置，我应该从 Controller 调用业务层来获取数据，并将与数据节点进行通信。

问题是在 Controller 和 View 中我将需要我绑定(bind)到的模型的数据类型/引用。 那么，我应该将自动生成的类保留在数据节点中，还是可以仅将生成的类移动到共享节点，然后将它们用于 Controller / View 中的绑定(bind)？哪一个将是一个好的实践？因为我不想直接在 Controller 中引用数据节点，否则没有必要像上面那样分离所有内容。

另一个简单的问题。我将通过 REST/SOAP 集成如此多的第三方 API。这些最适合哪一层？

如果有人有任何其他架构建议或我在这里缺少的东西，请提出建议。

提前感谢大家。

更新!!!

请参阅上面我更新的架构。

这是我到目前为止所做的。

• 我已添加存储库、服务和 IoC。
• 在我的 Global.asax 中，我正在初始化 IoC，它为我配置服务等。
• 我的 Controller 有一个重载的构造函数，现在将业务层的服务作为参数。
• Controller 调用服务来获取数据，服务则调用存储库来获取数据。
• 我遵循通用存储库路径，而不是为每种类型手动创建存储库
• 对于第 3 方 API，我将使用数据层，以后业务将不知道数据来自哪里。它只需要询问它需要什么。
• 在专用接口(interface)项目的帮助下，所有这一切都变得更加容易，需要时可以从业务层和数据层引用该项目。因为两者都想实现 abc 接口(interface)，所以我无法在业务层或数据层中声明它，因为这样会出现循环引用，这会阻止我相互引用两个(业务/数据)项目。

因此，在上述更改的帮助下，我现在可以轻松地做我想做的事情，并且一切都按照我想要的方式完美运行。现在我的最后一个问题是

这个架构有什么缺陷吗？

Answer 1

对于以域为中心的体系结构，可以轻松添加其他类型的 UI 或更改持久性技术，并且业务类可以轻松地单独测试，这就是我要做的:

• 没有依赖关系的业务层。定义业务类型和运营。

• 具有从数据库映射到业务类型的数据访问对象/存储库的数据层。您还可以将第三方 API 访问器和适配器放在这里。取决于声明存储库接口(interface)的业务层。

• 无共享层。业务类型是流经系统的基本“货币”。

• UI层依赖于业务中声明的数据访问接口(interface)，但不依赖于数据层。为了进一步解耦 UI，您可以引入一个额外的与 UI 无关的应用程序层。

您可以在Onion Architecture阅读更多相关信息。或Hexagonal Architecture .

事实上，您的架构很大程度上是数据驱动的(或 Telerik 数据驱动的)，因为业务和 UI 层与 Telerik 架构紧密耦合。这没有什么问题，但正如我在评论中所说，它可以实现其他功能，例如从现有数据库模式快速开发、完整的域解耦、框架不可知论和可测试性。

在我看来，您的 Telerik 生成的模型是否存在于数据模块或共享模块中，在这种情况下几乎没有什么区别。它仍然是整个应用程序的引用模型，并且您的 Controller 无论如何都会与其耦合。我唯一建议反对的是手动移动生成的文件 - 如果它可以完全自动化，那么一定要这样做，或者根本不移动文件。