2

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

所以，我从一个基于C# MVC5的大型Web 项目开始，我想以尽可能多的解耦方式组织所有内容。对于数据库部分，我将使用Telerik 的 Data Access 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 模式，它还将为我的数据库中的表生成类（默认配置）

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

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

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

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

提前谢谢大家。

更新！！！

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

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

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

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

这个架构有什么缺陷吗？

4

2 回答 2

3

For a domain-centric architecture where it's easy to add another type of UI or change persistence technology and where business classes are easily testable in isolation, here's what I'd do :

  • Business layer with no dependencies. Defines business types and operations.

  • Data layer with data access objects/repositories that map from database to business types. You can also put your third party API accessors and adapters here. Depends on Business layer where repository interfaces are declared.

  • No Shared layer. Business types are the basic "currency" that flows through your system.

  • UI layer depending on the data access interfaces declared in the Business, but not on the Data layer. To decouple UI further, you can introduce an additional UI-agnostic Application layer.

You can read more about this at Onion Architecture or Hexagonal Architecture.

As it is, your architecture is pretty much data-driven (or Telerik Data driven) since the business and UI layers are tightly coupled to the Telerik schema. There's nothing wrong with that, but as I said in my comment, it enables other things such as quick development from an existing database schema, over full domain decoupling, framework agnosticism and testability.

Whether your Telerik generated model lives in the Data or Shared module makes little difference in that scenario IMO. It is still the reference model throughout your application and your controllers will be coupled to it anyway. The only thing I would advise against is moving the generated files manually - if it can be automated all the way, definitely do it or don't move the files at all.

于 2014-10-26T10:00:19.917 回答
0

对于您的特殊技术，我既不是专家，也不会将此视为最终答案，但我给您一些提示，说明您可能拥有的可能性（取决于您的技术）：

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

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

拆分数据层的方法

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

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

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

构建外部 API

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

希望这有所帮助 ：）

于 2014-10-23T09:33:18.520 回答