In EF 4.1, can I have DBSet<ISomething> instead of DBSet<Something>?

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 th开发者_运维知识库en 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.

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.

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.