Question

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

所以，我开始使用基于Web的大规模 C＃MVC5 的Web项目，我希望尽可能多地以分离的方式组织所有内容。对于数据库部分，我将使用来自Telerik的数据访问ORM （以前称为Open Access），因为我将使用 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数据访问rlinq架构，它还将为我的数据库中的表生成类（默认配置）

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

问题是在控制器和视图中我将需要模型I＆＃39; m绑定的数据类型/引用。那么，我应该将自动生成的类保留在数据节点中，还是只能将生成的类移动到共享节点，然后在Controller / View中使用这些类进行绑定？哪一个是一个好习惯？因为我不想直接在控制器中引用数据节点，否则将上述所有内容分开是没有意义的。

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

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

先谢谢大家。

UPDATE !!!

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

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

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

所以，在上述变化的帮助下，我可以很容易地做我现在想做的事情，一切都按照我的要求完美运作。现在我的最后一个问题是

这个架构有什么缺陷吗？

Answer 1

对于以域为中心的架构，可以轻松添加其他类型的UI或更改持久性技术，以及业务类可以单独进行测试，这就是我要做的事情：

没有依赖关系的业务层。定义业务类型和操作。
具有从数据库映射到业务类型的数据访问对象/存储库的数据层。您也可以在此处放置第三方API访问器和适配器。取决于声明存储库 interfaces 的业务层。
没有共享图层。业务类型是流经系统的基本“货币”。
UI层取决于业务中声明的数据访问接口，但不取决于数据层。要进一步分离UI，您可以引入一个与UI无关的其他应用程序层。

您可以在Onion Architecture或Hexagonal Architecture了解详情。

实际上，由于业务和UI层紧密耦合到Telerik架构，因此您的架构几乎是数据驱动的（或Telerik数据驱动）。这没有什么不对，但正如我在评论中所说，它可以实现其他功能，例如从现有数据库模式快速开发，完全域解耦，框架不可知性和可测试性。

您的Telerik生成的模型是否存在于数据或共享模块中对于该场景IMO没什么影响。它仍然是整个应用程序的参考模型，无论如何，您的控制器都将与它耦合。我唯一建议的是手动移动生成的文件 - 如果它可以一直自动化，肯定是这样做或根本不移动文件。

Answer 2

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

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

目前我真的没有，为什么你的控制器和视图需要访问任何与数据库相关的东西？您的业务层不应该处理所有这些并将其从控制器和视图中隐藏吗？但是我们假设这是必要的。

分割数据层的方法

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

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

需要更多维护的解决方法是local extension。您可以在共享文件夹中创建新类，该文件夹派生自数据层类。

构建外部API

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

希望这有点帮助：）

需要大规模.Net MVC项目的建筑建议

2 个答案:

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

分割数据层的方法

构建外部API