0

我的业务逻辑和核心实体是紧密耦合的。

  • 例如，一个名为 Session 的对象是一个数据库实体，但从字面意义上来说，它是一个真实的 Session，在此期间会记录事件。
  • 此 Session 对象还具有 [NotMapped] 对象和非托管资源的句柄。
  • Session 对象也实现了 IDisposable。
  • 我的项目中有很多实体具有上述特征。

这听起来像是一场灾难。问题是在这里采取什么方法。

我期待答案指向设计模式或架构，但请包含一个非常简短的代码示例来说明您的观点，而不仅仅是提议的解决方案的名称。

到目前为止，我所想到的是将每个实体作为业务对象派生出来，并使用代码生成从一种类型转换为另一种类型。由于这是一个客户端/服务器应用程序，我希望能够在我的桌面应用程序中按原样使用实体关系集，尽管它是派生的。

不知道如何以可持续的方式实现这一目标。

4

1 回答 1

2

这不是关于设计模式，而是关于一次性实体的所有权。谁拥有实体？业主负责处置。那是您的代码/设计直接定义的东西。

EF 上下文本身是一次性的 - 您可以覆盖它的Dispose操作并强制它处理所有附加的实体，但这很可能是您不想做的事情，因为上下文很可能不是实体的所有者。从上下文请求实体或请求实体持久性的代码应被视为负责处置的所有者。

于 2012-05-12T12:53:55.313 回答