Entity Framework 4: какой подход является лучшим

Question

Я знаю, что подобные вопросы задавались ранее.

Я начинаю с набора сгенерированных xsd объектов данных (плюс есть модель db), и мне нужно сохранить эти почти 1: 1 в одной базе данных SQL Server. Количество сущностей невелико (10), и логика, необходимая для вставки / обновления / удаления БД (в основном upserts), невелика (хотя она и есть).

Мне интересно, какой подход лучше?

1. нет ORM с хранимыми процессами SQL Server, вероятно, сгенерированными с использованием T4 или что-то вроде codeSmith
2. Entity Fx, генерируйте сущности из Db и вручную отображайте xsd сущности в EFx сущности во время выполнения
3. Entity Fx, сгенерируйте файл edmx из БД, затем используйте подход POCO и напрямую сохранять сгенерированные xsd объекты (после ручного кодирования я полагаю, производный класс ObjectContext)
4. подход, основанный только на коде EFx (выглядит как одна из самых идиотских идей, которые я когда-либо видел)
5. что-нибудь еще?

Я особенно заинтересован в обслуживании: что произойдет, если свойство будет добавлено к сгенерированным XSD объектам, сколько усилий потребует каждый подход.

Я бы соблазнился перейти с 1, так как логика тонкая и нет сложных отображений (m: n). Но возможно, что модель данных будет развиваться в более сложную модель предметной области, и тогда мы не хотим ничего переопределять.

Насколько вреден каждый из подходов EFx с точки зрения производительности во время выполнения?

Answer 1

Ваше решение в этом случае должно в значительной степени зависеть от будущего направления вашей заявки.

Вам следует рассмотреть вариант 3 в первую очередь, если вы не хотите, чтобы ваши сущности имели какую-либо зависимость от сборки Entity Framework (System.Data.Entity). Если вы считаете, что хотите распространять или делиться своим слоем Entity / DAL / BL как независимой сборкой с другим приложением, рассмотрите вариант 3. Это позволит вам отделить ваши сущности от реализации постоянного хранения. Однако, если вы не ожидаете иметь несколько реализаций персистентности и не заботитесь о зависимости от сборок EF, параметры 1 или 2 будут работать просто отлично.

Кроме того, учитывая ограниченную логику сохранения, обязательно изучите скомпилированные запросы в Entity Framework для значительного улучшения производительности.