手动编写业务对象还是使用 DAL 对象？

Posted 2023-02-24

【中文标题】手动编写业务对象还是使用 DAL 对象？

【英文标题】：Manually written business objects or using DAL objects?

【发布时间】：2010-10-30 22:28:47

【问题描述】：

假设您有三层（带有命名空间）：

用户界面 (App.UI) - 调用业务层流程并使用对象进行通信 业务层 (App.Core) - 编排流程并使用对象使用 DAL 层 DAL (App.Data) - 直接操作存储和持久化对象

假设您有 User 表，因此反映在 App.Data.User 和可能还有 App.Data.Users 的 DAL 层中。

您的 UI 中有一个显示应用程序用户的视图。

要真正拥有一个分离（分层）的应用程序，您还应该拥有App.Core.User 和App.Core.Users，您可能必须手动创建它们。

最佳解决方案（在我看来）当然是： 应该有第四层 Business Objects (App.Objects)，其类为 App.Objects.User 和 App.Objects.Users。这些 POCO 将在所有层之间共享。业务层只允许使用 DAL，UI 只允许使用 BL，但它们都将App.Objects 用于公共对象模型。

Asp.net MVC 模板暗示直接在视图上使用 DAL 对象，LINQ 2 实体本身也不创建任何 POCO...

那么当使用任何自动代码生成时，我们应该使用 DAL 对象还是手动硬编码我们共享的 POCO？ 第一部分似乎是一个简单的出路 但没有将 DAL 与 UI 分开（以后可能会有安全性和可扩展性问题），第二个容易出错并且对于中等大小的数据库非常繁琐。

你有什么建议？

【参考方案1】：

您所谓的 App.Objects 基本上是您的领域模型，在所有层之间共享以传递数据是合乎逻辑的，但您需要确定此模型是贫乏的还是活跃的。