我正在尝试使用业务方法构建域模型，并让EF 4.1为我做持久性。到目前为止一切都很好。
问题是，所有属性都在我的域类中公开。这至少是我从教程中学到的东西。这意味着，我没有强有力的证据证明类属性不会被业务方法之外的一些粗心的程序员改变。封装违反了。
我尝试引入ISomething，但TableAttribute仅适用于类，而不适用于接口，所以我不能告诉EF做DBSet。如果我将TableAttribute留给类但是无论如何都要使Something实现ISomething，那么我不能做DBSet.Add（），因为EF不知道ISomething。
我能想到的唯一方法是使用接口在EF 4.1上为CRUD编写完整的抽象层。在幕后，在Something和ISomething之间进行类型转换。这听起来很复杂，而且EF的设计也是一个巨大的漏洞。或者我一定错过了什么。
你会如何解决这个问题？
非常感谢。
答案 0 :(得分：1)
问题是，所有属性都在我的域类中公开。 这至少是我从教程中学到的东西。那意味着，我 没有强有力的证据证明类属性不会被某些人改变 商业方法之外的粗心程序员。封装 侵犯。
接口如何解决这个问题？接口将再次公开所有属性，因为public和EF要求属性必须具有getter和setter。
EF无法使用接口。当使用EDMX进行映射时，可以使用属性的可访问性进行一点点操作，但是当首先使用代码时，它会更糟糕，因为映射会受到相同的可访问性规则的影响。在EF之上创建抽象层与完全不使用EF完全相同。一旦你创建了抽象，就不能直接使用linq-to-entities，你将失去使用EF的主要原因。
你的问题更多的是：边界在哪里？如果您只想在业务方法中使用实体，则不应从这些方法中公开它们。如果要确保正确处理属性，可能应该直接在实体中实现验证逻辑。