需要大型.Net MVC项目的体系结构建议

本文关键字：结构 构建 项目 大型 Net MVC | 更新日期: 2023-09-27 18:27:34

我会尽可能详细地解释。SO上可能也有类似的问题，我已经经历了所有这些，但没有一个符合我的需求。

因此，我从一个基于C#MVC5的大规模Web项目开始，我希望以尽可能解耦的方式组织一切。对于数据库部分，我将使用Telerik（以前称为Open Access）的Data Access 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项目中绑定模型时，如果您的解决方案中只有一个项目，那么它可以很容易地工作而不会出现问题。

即在MVC控制器中

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

然后在相应的视图中，您在顶部使用此

@model (model type here)

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

现在，从上面的设置中，从控制器中，我应该调用业务层来获取数据，它将与data节点通信。

问题是，在控制器和视图中，我将需要绑定到的模型的数据类型/引用。那么，我应该将自动生成的类保留在数据节点中吗？还是可以仅将生成的类移动到共享节点，然后将其用于控制器/视图中的绑定？哪一个会是一个好的练习？因为我不想直接引用控制器中的Data节点，否则就没有必要像上面那样分离所有内容

另一个快速问题。我会通过REST/SOAP集成这么多第三方API。这些最适合哪一层？

如果有人有任何其他建筑建议或我在这里遗漏的东西，请提出建议。

提前感谢大家。

更新

请参阅上面我更新的体系结构。

以下是我到目前为止所做的。

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

所以，有了以上的改变，我现在可以很容易地做我想做的事情，一切都像我想的那样完美。现在我的最后一个问题是

此体系结构中是否存在任何缺陷

需要大型.Net MVC项目的体系结构建议

对于一个以域为中心的体系结构，在该体系结构中可以很容易地添加另一种类型的UI或更改持久性技术，并且业务类可以很容易隔离地进行测试，我会这样做：

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

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

  • 没有共享层。业务类型是流经系统的基本"货币"。

  • UI层取决于在业务中声明的数据访问接口，但不取决于数据层。为了进一步解耦UI，您可以引入一个额外的UI不可知的应用程序层。

你可以在洋葱建筑或六边形建筑上阅读更多关于这方面的内容。

实际上，您的体系结构基本上是数据驱动的（或Telerik数据驱动的），因为业务层和UI层与Telerik模式紧密耦合。这并没有错，但正如我在评论中所说，它可以实现其他功能，如从现有数据库模式快速开发、跨域解耦、框架不可知性和可测试性。

无论您的Telerik生成的模型是位于数据模块还是共享模块中，在这种情况下都没有什么不同。IMO。它仍然是整个应用程序的参考模型，您的控制器无论如何都会与它耦合。我唯一建议不要手动移动生成的文件——如果它可以一直自动化，那么一定要这样做，或者根本不移动文件。

我不是您的特殊技术的专家，我也不认为这是最终的答案，但我给您一些可能的提示（取决于您的技术）：

企业应具有对数据的独占访问权限

目前我真的不明白，为什么你的控制器和视图需要访问任何数据库相关的东西？难道您的业务层不应该处理所有这些并将其隐藏在控制器和视图之外吗？但让我们假设出于某种原因这是必要的。

拆分数据层的方法

您不应该手动移动生成的类。您可以更改您的生成设置，以便在其他地方部分生成它们。但是手动挑选和移动它们会导致架构难以维护。

如果可以更改类的可见性，则更干净的解决方案是。是否可以生成具有项目或文件夹可见性的类？或者只能导出项目设置中定义的包或类？

需要更多维护的解决方法是本地扩展。您可以在共享文件夹中创建新的类，这些类派生自数据层类。

构建外部API

给他们一个或多个自己的项目，这样他们以后更容易更改。我知道的方法是每个API都有一个主文件夹。这使得它们中的每一个都很容易更改，但会扰乱您的工作空间。这一重要项目将仅为1000个项目中的4个。我通常更喜欢一个包含所有API的文件夹。因此，API稍微难以更改，但您的工作区保持干净。您的决定取决于两个事实：更改、添加、删除API的频率，或者只是研究API。IDE是否提供了一种从工作区"隐藏"文件夹/项目的方法。

希望这能有所帮助：）

相关文章：