【问题标题】:Manually written business objects or using DAL objects?手动编写业务对象还是使用 DAL 对象?
【发布时间】: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.UserApp.Core.Users,您可能必须手动创建它们。

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

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

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

你有什么建议?

【问题讨论】:

    标签: code-generation poco data-access-layer n-tier-architecture


    【解决方案1】:

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

    【讨论】:

      猜你喜欢
      • 2010-09-15
      • 1970-01-01
      • 1970-01-01
      • 2023-03-23
      • 1970-01-01
      • 2010-12-20
      • 2012-08-03
      • 2012-01-23
      • 2011-09-04
      相关资源
      最近更新 更多