Я делаю следующее:
Сервисный слой содержит мои бизнес-объекты. Он передается в хранилище с помощью Inversion of Control (Castle Windor - мой обычный выбор). Хранилище отвечает за сопоставление между бизнес-объектами и объектами моей сущности.
Преимущества: у вас нет проблем с состоянием объекта или контекстом объектов EF, поскольку вы просто загружаете их во время манипулирования данными на стороне хранилища. Это облегчает ситуацию при передаче их в WCF / Web-сервисы.
Недостатки: Вы теряете некоторые функции отслеживания Entity Framework, вам приходится вручную загружать объект данных (объекты ef), возможно, при необходимости вручную, для оптимистических проверок параллелизма (например, с помощью отметки времени на бизнес-объекте) ,
Но, как правило, я предпочитаю это решение, потому что позже можно изменить хранилище. Это позволяет мне иметь разные репозитории (например, мой пользовательский объект фактически использует ASPNetAuthenticationRepository вместо EntityFrameworkRepository), но для моего сервисного уровня это прозрачно.
Что касается интерфейса, я бы использовал бизнес-объекты из сервисного уровня в качестве объектов параметров и не позволял бы этим объектам EF выходить из уровня репозитория.
Надеюсь, что это поможет