【问题标题】:Entity framework and n-layered application实体框架和 n 层应用程序
【发布时间】:2012-05-15 23:39:28
【问题描述】:

所以,我有这个:

  1. 网络应用
  2. 业务逻辑
  3. 数据访问逻辑

我在数据访问逻辑、实体、上下文、初始化器中创建。

所以通常较高层调用较低层的功能,对吧?

如果我想保存一个客户,我想从网络应用创建一个客户实体。我不喜欢从 Web 应用层直接引用到数据访问逻辑层(类库)

有什么想法吗?

【问题讨论】:

    标签: entity-framework entity-framework-4


    【解决方案1】:

    我知道这可能不是很有建设性,但如果我是你,我会添加参考。没有必要让你自己更难找到一种更复杂的方法来做一些应该很容易的事情。另外,如果您现在跳过它并稍后遇到更好的解决方案,您可以修改您的代码。

    【讨论】:

      【解决方案2】:

      这就是我在之前的项目中的做法

      我的解决方案下的 4 个项目

      1) UI(我的 ASP.NET MVC 应用程序)

      2) 商业实体(我的 POCOS 用于客户、订单等实体)

      3) 业务逻辑(我的中间服务层,位于 UI 和 DataAccess 层之间。我会在这里进行特定于业务的验证。

      4) 数据访问层。与我的数据库对话。可以是EF/纯ADO.NET Stored Proc等。

      • DataAccessLayer 项目有业务实体项目的引用
      • 业务逻辑项目有业务实体项目的参考
      • UI 项目有 Business Entities Project 和 BusinessLogic 的引用。

      在 UI 中,我调用中间层(业务逻辑)的方法,在进行自定义验证/业务规则之后,我将调用数据访问层方法。

      【讨论】:

      • 将业务实体公开给所有层而不是在服务层中编写自定义数据传输对象时的优缺点是什么?您的 UI 层是否能够访问 DB 访问对象?
      • @null:在上述方法中,数据访问层返回加载的业务对象。 ex :对于 GetUser 方法,它返回一个在业务实体项目中定义的用户实体对象,如 ORM。这些对象表示几乎与 db 实体相同。对于自定义 UI 实体,我会使用 ViewModels。
      • 我的解决方案是一个通用版本,它也支持非实体框架场景。如果我使用 EF,我不会在我的业务对象中创建 POCO。我使用这些并将它们映射到映射层中的 ViewModel
      猜你喜欢
      • 2014-12-10
      • 2012-12-17
      • 2012-03-28
      • 1970-01-01
      • 2011-08-22
      • 1970-01-01
      • 2012-03-04
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多