architecture - n 层架构 - BLL、DAL 和接口(interface)。什么是最佳实践?

标签 architecture orm data-access-layer bll n-layer

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

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

我的问题是在另一侧创建对象的最佳方法是什么?例如,如果我在 BLL 中有一个实现 IPerson 的 Person 对象,以及一个 PersonDataObject 或 DLL 中也实现 IPerson 的任何对象,我将 Person 传递给 DAL 中的一个方法,该方法采用 IPerson 的参数,然后在 DAL 中我' d 必须重建一个 PersonDataObject 才能持久化。这是最好的方法吗?

抱歉,我可能还没有很好地解释这一点,因为我很困惑。非常感谢假人回答的最佳做法。

最佳答案

一般来说,BLL 中的对象将使用接口(interface)——而不是实现它们:

For example if I had a Person object in the BLL that implemented IPerson, and a PersonDataObject or whatever in the DLL that also implements IPerson

以“人”为例:思考与一个人相关的不同数据操作(获取单个人的所有数据、多人的浅层数据集合、CRUD操作、搜索等)——然后沿着逻辑分组设计界面(参见 Interface Segeragtion Principle )。

接口(interface)可能表示从以 BL 为中心的角度或基于“服务”的角度的操作。

无论如何,回答你的具体问题......

我在通用程序集中定义了 DTO 的等价物,在单独的程序集中定义了数据接口(interface) - 所以我有 4 个程序集:BL、数据访问接口(interface)定义、接口(interface)实现和通用;所有程序集都引用通用程序集。

我在 C#.Net 中工作,我将 DTO 定义为结构(但您可以使用类);并且它们的所有属性都是只读的 - 您在构造函数中将数据输入它们 - 这样 DTO 实际上是信息的“哑”信封。

关于architecture - n 层架构 - BLL、DAL 和接口(interface)。什么是最佳实践?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3121870/

相关文章:

architecture - Java EE 类加载标准

sql - 值得自己测试数据访问查询吗?

当指定 armv7 时,iOS 项目为 armv6 构建(目标是 iOS 5.1)

java - 复制 @ElementCollection 行为

java - JPQL:查询多列时,什么样的对象包含结果列表?

php - ORM 的 FuelPHP 更新偶尔会导致“而不是”

java - SQL 中的占位符

architecture - MVVM、业务逻辑、实体、DTO 并将它们捆绑在一起

java - 组合 vs 多个单例

c# - PerlNet 的局限性是什么?