c# - n层架构: best place to store business objects?

Question

假设我有一个 3 层架构(UI、业务和数据)。通常，我会创建一个名为“Model”或“Common”的第四个项目来保存我的数据访问对象，然后每个其他项目都会使用这个项目。

现在我正在处理一个项目，其中我的一些数据访问对象具有 Save() 等需要访问数据项目的方法。因此，如果我尝试在 Data 项目中使用 Model/Common 项目，我将得到一个循环引用。

在这种情况下，保存数据访问对象的最佳位置在哪里？我可以将它保留在数据项目本身中，但是我的 UI 项目需要了解数据访问对象，因此需要访问数据层，这并不好。

Answer 1

我认为您的 n 层不太正确。听起来您正在构建更多的 2 层系统。

在真正的 3 层项目中，只允许您的数据层与数据库对话。你有你的“模型”或“通用”项目。这些项目是您的数据层。但是你偏离的地方是只有业务层应该被允许与他们交谈。根本不应允许您的表示代码与数据层项目对话。

当你有超过 3 个“层”时，n-Tier 就会出现，但应用程序的原则是相同的:每个层只知道如何使用(并且只需要引用)它下面的那个，然后为它提供一个 api它上面的层。在我自己的项目中，我采用典型的表示层、业务层和数据层，并在业务和数据之间提供第 4 个“转换”层。这样，数据层可以返回通用类型，如数据集、数据表和数据行，而业务层仅必须根据强类型业务对象工作。翻译层仅在通用数据对象和强类型对象之间进行转换。这样，对其中一个传统层的更改不太可能需要对另一个进行更改。