В EF 4.1 можно ли использовать DBSet <ISomething>вместо DBSet <Something>?

Question

Я пытаюсь построить модель предметной области с помощью бизнес-методов, и у меня есть постоянство для EF 4.1. Пока все хорошо.

Проблема в том, что все свойства выставлены как открытые для классов моего домена. Во всяком случае, это то, что я узнал из этого урока. Это означает, что у меня нет убедительных доказательств того, что некоторые небрежные программисты не изменят свойства класса вне бизнес-методов. Инкапсуляция нарушена.

Я пытался представить ISomething, но TableAttribute применяется только к классам, а не к интерфейсам, поэтому я не могу сказать EF сделать DBSet. Если я оставлю TableAttribute классам, но заставлю Something реализовать ISomething в любом случае, тогда я не смогу выполнить DBSet.Add (), потому что EF не знает ISomething.

Единственный способ, о котором я могу думать, - это написать полный уровень абстракции поверх EF 4.1 для CRUD с использованием интерфейсов. Под капотом сделайте перевод типа между Something и ISomething. Звучало много сложности и зияющей дыры в дизайне EF. Или я, должно быть, что-то пропустил.

Как бы вы решили это?

Большое спасибо.

Answer 1

Проблема в том, что все свойства выставлены как открытые для классов моего домена. Во всяком случае, это то, что я узнал из этого урока. Это означает, что я нет веских доказательств того, что свойства класса не изменятся некоторыми неосторожные программисты вне бизнес-методов. Инкапсуляция нарушается.

Как это будет решаться интерфейсом? Интерфейс снова выставит все свойства как публичные, а EF требует, чтобы свойство имело геттер и сеттер.

EF не умеет работать с интерфейсами. При использовании EDMX для отображения можно немного поиграть с доступностью свойств, но при использовании кода сначала это намного хуже, потому что на отображение влияют те же правила доступности. Создание слоя абстракции поверх EF - это почти то же самое, что вообще не использовать EF. Создав абстракцию, вы не сможете напрямую использовать linq-to-entity и потеряете основную причину использования EF.

Ваша проблема в следующем: где граница? Если вы хотите работать с сущностями только в бизнес-методах, вы не должны подвергать их этим методам. Если вы хотите убедиться, что свойства обрабатываются правильно, возможно, вам следует реализовать логику проверки непосредственно в сущности.