title: In EF 4.1, can I have DBSet<ISomething> instead of DBSet<Something>?
body: <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>How would you solve this?</p>
  
  <p>Many thanks.</p>