1

我正在尝试使用业务方法构建域模型并让 EF 4.1 为我做持久性。到目前为止，一切都很好。

问题是，所有属性都在我的域类中公开。无论如何，这至少是我从教程中学到的。这意味着，我没有强有力的证据证明类属性不会被业务方法之外的一些粗心的程序员改变。违反封装。

我尝试引入 ISomething 但 TableAttribute 仅适用于类，不适用于接口，所以我不能告诉 EF 做 DBSet。如果我将 TableAttribute 留给类，但无论如何都要让 Something 实现 ISomething，那么我不能执行 DBSet.Add()，因为 EF 不知道 ISomething。

我能想到的唯一方法是在 EF 4.1 之上使用接口为 CRUD 编写一个完整的抽象层。在引擎盖下，做Something 和ISomething 之间的类型转换。这听起来很复杂，而且 EF 的设计存在巨大的漏洞。或者我一定错过了什么。

你会如何解决这个问题？

非常感谢。

4

1 回答 1

1

问题是，所有属性都在我的域类中公开。无论如何，这至少是我从教程中学到的。这意味着，我没有强有力的证据证明类属性不会被业务方法之外的一些粗心的程序员改变。违反封装。

这将如何通过接口解决？接口将再次将所有属性公开为公共属性，并且 EF 要求属性必须具有 getter 和 setter。

EF 无法使用接口。当使用 EDMX 进行映射时，可以稍微使用属性的可访问性，但是当首先使用代码时，情况会更糟，因为映射受到相同的可访问性规则的影响。在 EF 之上创建抽象层与根本不使用 EF 基本相同。创建抽象后，您将无法直接使用 linq-to-entities，您将失去使用 EF 的主要原因。

你的问题更多是关于：边界在哪里？如果您只想在业务方法中使用实体，则不应从这些方法中公开它们。如果您想确保正确处理属性，也许您应该直接在实体中实现验证逻辑。

于 2011-07-27T09:07:53.813 回答