Architecture n层架构——BLL、DAL和接口。什么是最佳实践？

我有一个关于n层架构的问题。在问这个问题之前我想了很久，因为这里已经有很多类似的问题了。。。然而，经过一天半的观察和阅读这些其他答案后，我仍然不确定。各种看似相似的术语和不同的方法让我感到困惑

如果我在不同的类库中有一个BLL和一个DAL，BLL和DAL之间通信的一种方式就是使用一个接口，有点像是在另一个单独的DLL中定义的DTO，由BLL和DAL引用。BLL中我的域模型实体将实现此接口，DAL中任何ORM生成的对象也将实现此接口。为了保存我的业务实体，我可以将它们传递给DAL，DAL会很好地接受它们，因为它们实现了共享接口。我还可以将对象传递回实现该接口的BLL。这似乎是合理的，因为BLL和DAL只需要知道基本接口，而不需要知道彼此的具体实现

我的问题是，在另一边创建对象的最佳方法是什么？例如，如果我在BLL中有一个Person对象实现了IPerson，在DLL中有一个PersonDataObject或其他任何东西也实现了IPerson，我将Person传递给DAL中的一个方法，该方法采用IPerson参数，那么在DAL中，我必须重构PersonDataObject才能持久。这是最好的方法吗

---

对不起，我可能没有解释清楚，因为我很困惑。如果能为傻瓜提供最佳实践答案，我们将不胜感激。

谷歌领域驱动设计和存储库模式。它表明，您的体系结构正朝着这个方向发展，根据场景的需要，我将在更复杂的代码上使用这种方法。

一般来说，BLL中的对象将使用接口，而不是实现它们：

例如，如果我有一个Person对象 在实施IPerson的BLL中， 还有一个PersonDataObject或者其他什么 也实现IPerson的DLL

以“个人”为例：考虑与个人相关的不同数据操作（为单个个人获取所有数据、为多个人收集浅层数据、CRUD操作、搜索等），然后按照逻辑分组设计接口（请参阅）

这些接口可以从以BL为中心的角度来表示操作，也可以从基于“服务”的角度来表示操作

无论如何，要回答你的具体问题

我在一个公共程序集中定义了DTO的等价物，在一个单独的程序集中定义了数据接口——因此我有4个程序集：BL、数据访问接口定义、接口实现和公共；所有程序集都引用公共程序集

---

我在C#.Net中工作，我将DTO定义为结构（但可以使用类）；所有这些属性都是只读的——您可以在构造函数中将数据输入到它们中——这样DTO实际上就是信息的“哑”信封。

在遵循n层体系结构的同时，在BL和DAL之间共享数据对象是非常常见的。有时，在UI层中也可以使用相同的数据对象

---

通常，我有一个数据模型（或数据对象或域模型，不管你怎么称呼它）程序集，它将所有模型对象作为接口来容纳。以您的人员为例，我将在模型组装中创建一个IPeople接口。DAL将向BL返回一个IPeople实例。BL将使用该实例，如果需要，在应用业务逻辑后将其传递到UI层。

还有我忘记包含的一点：让BL调用一个“工厂”方法，负责实例化具体实现；我倾向于在配置中定义它们，因为它们很容易更改。