在 EF 4.1 中，我可以使用 DBSet吗？而不是 DBSet？
我正在尝试使用业务方法构建域模型，并让 EF 4.1 为我做持久化工作。到目前为止，一切都很好。
问题是，所有属性在我的域类上都公开公开。无论如何，这至少是我从教程中学到的。这意味着，我没有强有力的证据证明类属性不会被业务方法之外的一些粗心程序员更改。封装被破坏。
我尝试引入 ISomething 但 TableAttribute 仅适用于类，而不适用于接口，因此我无法告诉 EF 执行 DBSet。如果我将 TableAttribute 留给类，但无论如何都要让 Something 实现 ISomething，那么我就无法执行 DBSet.Add()，因为 EF 不知道 ISomething。
我能想到的唯一方法是使用接口在 EF 4.1 之上为 CRUD 编写一个完整的抽象层。在底层，在 Something 和 ISomething 之间进行类型转换。这听起来很复杂，而且 EF 的设计中存在很大的漏洞。或者我一定错过了什么。
你会如何解决这个问题？
非常感谢。
I am trying to build a domain model with business methods and have EF 4.1 doing the persistence for me. So far so good.
Problem is, all properties are exposed as public on my domain classes. That's at least what I learnt from the tutorial anyway. That means, I have no strong proof that class properties won't change by some careless programmers outside of business methods. Encapsulation violated.
I tried introducing ISomething but TableAttribute applies only to classes, not interfaces, so I can't tell EF to do DBSet. If I leave TableAttribute to classes but make Something implement ISomething anyway then I can't do DBSet.Add() because EF doesn't know ISomething.
The only way I can think of is write a complete abstraction layer on top of EF 4.1 for CRUD using interfaces. Under the hood, do the type translation between Something and ISomething. It sounded a lot of complexity and a gaping hole in EF's design. Or I must've missed something.
How would you solve this?
Many thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
通过接口如何解决这个问题？接口将再次将所有属性公开为公共属性，并且 EF 要求属性必须具有 getter 和 setter。
EF 无法使用接口。当使用 EDMX 进行映射时，可以稍微调整一下属性的可访问性，但是当首先使用代码时，情况会更糟，因为映射受到相同的可访问性规则的影响。在 EF 之上创建抽象层与根本不使用 EF 基本相同。一旦创建了抽象，您就无法直接使用 linq-to-entities，并且您将失去使用 EF 的主要原因。
你的问题更多的是：边界在哪里？如果您只想在业务方法中使用实体，则不应从这些方法中公开它们。如果您想确保正确处理属性，也许您应该直接在实体中实现验证逻辑。
How this will be solved by interface? Interface will again expose all properties as public and EF demands that property must have getter and setter.
EF is not able to work with interfaces. When using EDMX for mapping it is possible to play little bit with properties' accessibility but when using code first it is much worse because mapping is affected by the same accessibility rules. Creating abstraction layer on top of EF is mostly same as not using EF at all. Once you create abstraction you cannot use linq-to-entities directly and you will lose main reason for using EF.
Your problem is more about: Where is the boundary? If you want to work with entities only in business methods you should not expose them from these methods. If you want to make sure that properties are correctly handled perhaps you should implement validation logic directly into the entity.