#.net #entity-framework #architecture
Вопрос:
Я рассматриваю возможность применения Entity Framework в новом проекте, потому что мне понравился его ИЛИ/M-API, а также возможности отображения хранилища/концептуальной модели (плюс, конечно, Linq и Entity SQL).
Но как может быть достигнута слабая связь между уровнем пользовательского интерфейса и бизнес-уровнем, если сущности EF используются в качестве носителей данных в обоих. Если я оставлю сущности, прикрепленные к их объектконтексту, пока они находятся в пользовательском интерфейсе, пользовательский интерфейс может обойти бизнес-уровень и подключиться непосредственно к базе данных. Если я отсоединю сущности от их ObjectContext перед передачей их в пользовательский интерфейс, отслеживания изменений не будет, поэтому мне придется «воспроизвести» все изменения на бизнес-уровне, чтобы они сохранялись в базе данных (трудно достичь, особенно. с отношениями между родителями и детьми). Хотя я не хочу, чтобы бизнес-уровень деградировал до «механизма сохранения дерева объектов», есть сценарии, в которых эта способность была бы полезной.
Это, безусловно, относится и к другим устройствам отображения ИЛИ, но некоторые альтернативные продукты, по-видимому, имеют несколько лучшие механизмы отсоединения/крепления.
Ответ №1:
«Воспроизвести» изменения проще, чем вы думаете. Вот общий план того, что вам нужно сделать:
- Сохраните «исходную» версию экземпляра сущности, прежде чем отсоединять ее и передавать в пользовательский интерфейс.
- Пусть пользовательский интерфейс делает свое дело.
- Если вы хотите сохранить изменения, внесенные пользовательским интерфейсом в базу данных, возьмите исходную версию, которую вы сохранили, и прикрепите ее к EntityContext. Примените изменения из измененной версии, возвращенной пользовательским интерфейсом, к этому экземпляру. Теперь сохраните изменения. Структура сущностей будет обрабатывать трехстороннее слияние.
Комментарии:
1. В целом хороший подход. Но где я должен «хранить» исходную версию (особенно на уровне службы stateles)? Или вы подразумеваете перезагрузку из БД? Кроме того, как насчет детских коллекций? Как можно узнать, какие дочерние объекты были вставлены/удалены, если состояние не изменилось?
Ответ №2:
Я не знаю ни одного ORM, который бы изящно работал с решениями n-уровня, в которых вы хотите иметь независимость от платформы. EF хорошо работает, когда все происходит в контексте объекта, когда у вас есть n-уровневое решение (физическое разделение, вызовы веб-служб WCF/XML), вам нужно выполнить некоторые действия, чтобы заставить объекты вести себя правильно.
Вы можете добиться слабой связи, используя шаблон репозитория для разделения зависимостей api от Ef (http://blog.keithpatton.com/2008/05/29/Polymorphic Репозиторий Для ADONet Entity Framework.aspx). Однако, если вы используете свои классы EF непосредственно на уровне пользовательского интерфейса, у вас будет зависимость от определенных типов, таких как EntityReference, EntityKey и EntityObject, если только вы не решите углубиться в мир того, как заставить EF работать с чистыми классами C# (POCO), что кажется мне более сложным, чем того стоит.
Ответ №3:
Дэниел Симмонс, из АДО.Команда Net предоставила метод расширения «AttachAsModified» для присоединения измененного объекта.
Это не так умно, как воспроизведение изменений, но это делает его : я использую его в качестве примера проекта.
Ответ №4:
Погуглите «Entity framework» и «вотум недоверия» и посмотрите, что вы получите.
Комментарии:
1. На самом деле, оглядываясь назад на то время, когда я опубликовал это, я замечаю, как эволюционировала Entity Framework. Проблема в то время была основана на том факте, что нужно было напрямую привязаться к EF, чтобы использовать его. Сейчас все изменилось к (гораздо) лучшему.