Стратегии замены устаревшего слоя данных структурой Entity и классами POCO

Question

Мы используем .net C # 4.0, VS 2010, EF 4.1 и унаследованный код в этом проекте, над которым мы работаем.

Я работаю над проектом формы win, где я принял решение начатьиспользование сущности 4.1 для доступа к MS SQL DB.База кода довольно старая, и у нас есть существующий уровень данных, который использует адаптеры данных.Эти адаптеры данных используются повсеместно (в веб-приложениях и приложениях для выигрышных форм). Я планирую со временем заменить старый код доступа к БД на EF и избавиться от тесной связи между уровнями пользовательского интерфейса и уровнем данных.

Таким образом, моя идея состоит в том, чтобы более или менее объединить EF с унаследованным уровнем доступа к данным и постепенно заменить унаследованный уровень данных более современным подходом к использованию EF.Поэтому на данный момент нам нужно использовать как EF, так и устаревший код доступа к БД.

На данный момент я добавил проект, содержащий файл edmx и контекст.EDMX генерируется с использованием базы данных первым подходом.Я также добавил еще один проект, который содержит классы POCO (с помощью ADO.NET POCO Entity Generator).Я более или менее следовал подходу Джулии Лерман в ее книге «Программирование Entity Framework» о том, как разделить модель и сгенерированные классы POCO.Модель базы данных была установлена ​​в течение многих лет, и это не вариант, чтобы изменить таблицу и отношения, триггеры, хранимые процедуры и т. Д., Поэтому я в основном застрял с моделью db, как она есть.

Я читал о шаблоне репозитория и единице работы, и мне нравятся шаблоны, но я изо всех сил пытаюсь реализовать их, когда у меня есть и EF, и устаревший код доступа к db.Особенно, когда у меня нет времени, чтобы заменить весь устаревший код доступа к БД чистой реализацией EF.В идеальном мире я бы начал все сначала со свежей модели данных, но здесь это не вариант.

Являются ли шаблоны репозитория и единицы работы подходящими?Чтобы использовать классы POCO на моем бизнес-уровне, мне иногда нужно использовать как EF, так и унаследованный код БД для заполнения моих классов POCO.Другими словами, я иногда могу использовать EF для извлечения части данных, которые мне нужны, и использовать старый уровень доступа к БД для извлечения остальных данных, а затем сопоставить данные с моими классами POCO.Когда я хочу обновить некоторые данные, мне нужно выбрать данные из классов POCO и использовать устаревший код доступа к данным для хранения данных в базе данных.Поэтому мне нужно отобразить данные, полученные из унаследованного слоя доступа к данным, в мои классы POCO, когда я хочу отобразить данные в пользовательском интерфейсе, и наоборот, когда я хочу сохранить данные в базе данных.

Чтобы усложнитьвещи, в которых мы храним некоторые данные в таблицах, имя которых мы не знаем до выполнения (пожалуйста, не спрашивайте меня, почему :-)).Поэтому на старом уровне доступа к БД нам пришлось создавать операторы SQL на лету, куда мы вставляли имена таблиц и столбцов на основе информации из других таблиц.

Я также обнаружил, что отношения между классами POCO несколькослишком база данных ориентирована.Другими словами, я чувствую, что мне нужна более упрощенная модель предметной области для работы.Возможно, мне следует создать модель предметной области, которая отвечает всем требованиям, а затем использовать классы POCO в качестве «DAO» для заполнения классов модели предметной области?

Как бы вы реализовали это, используя шаблон репозитория и шаблон единицы работы?(если это путь)

Answer 1

Сигналы тревоги звучат для меня!Мы пытались сделать нечто подобное некоторое время назад (только с nHibernate, а не EF4).У нас было несколько проблем с запуском ADO.NET наряду с параллельным выполнением ORM - большой проблемой.

Модель базы данных была установлена ​​годами, и изменение таблицы и отношений, триггеров, хранимых процедур и т. Д. Невозможно, поэтому я в основном придерживаюсь модели db как она есть.

Да.То же самое!Проблема заключалась в том, что наши хранимые процессы содержали много бизнес-логики и не были простыми CRUD-процессами, поэтому постоянно обновлять ORM с помощью различных обновлений, выполняемых хранимой процедурой - принцип единой ответственности - нехорошо нарушать!

Мой план состоит в том, чтобы со временем заменить старый код доступа к БД на EF и избавиться от жесткой связи
между уровнями пользовательского интерфейса и уровнем данных.

Может быть, вы могли бы отделить без необходимости ORM - как насчет размещения слоя службы / фасада перед вашим слоем пользовательского интерфейса, чтобы координировать все взаимодействия с базовым доменом и скрывать его от пользовательского интерфейса.

Если ваша база данных «король», а ваше приложение ориентировано на данные, я думаю, что вы всегда будете сражаться в тяжелом сражении, применяя упомянутые вами шаблоны.

Включите ado.net для этого проекта -используйте паттерны EF4 и DDD на вашем следующем зеленом поле proj:)

Answer 2

Генератор класса EDMX + POCO приводит к коду EFv4, а не к коду EFv4.1, но вам не нужно беспокоиться об этих деталях. EFv4.1 предлагает просто другой API, который делает то же самое (и это только оболочка вокруг EFv4 API).

В зависимости от того, как вы используете наборы данных, вы можете столкнуться с некоторыми очень сложными проблемами. Наборы данных являются представлением шаблона набора изменений. Они знают, какие изменения были внесены в данные, и могут хранить только эти изменения. Объекты EF знают это, только если они присоединены к контексту, который загрузил их из базы данных. Работая с отсоединенными сущностями, вы должны приложить большие усилия, чтобы сообщить EF, что изменилось - , особенно при изменении отношений (отсоединенные сущности являются распространенным сценарием в веб-приложениях и веб-службах). Для этих целей EF предлагает другой шаблон, который называется Самообследуемые сущности , но у них есть другие проблемы и ограничения (например, отсутствует отложенная загрузка, вы не можете применить изменения, когда присоединен объект с тем же ключом к контексту и т. д.).

EF также не поддерживает некоторые функции, используемые в наборах данных - например, уникальные ключи и пакетные обновления . Забавно, что новые API-интерфейсы MS обычно решают некоторые проблемы предыдущих API, но в то же время предоставляют гораздо меньше возможностей, чем предыдущие API, что вводит новые проблемы.

Другая проблема может быть связана с производительностью: EF медленнее, чем прямой доступ к данным с наборами данных, и имеет более высокое потребление памяти (и да, сообщается о некоторых утечках памяти).

Вы можете забыть об использовании EF для доступа к таблицам, которые вы не знаете во время разработки. EF не допускает динамического поведения. Имена таблиц и тип сервера базы данных фиксируются в отображении. Другая проблема может быть связана с тем, как вы используете триггеры - инструментам ORM не нравятся триггеры, а EF имеет ограниченные возможности при работе с вычисленными значениями базы данных (возможность заполнения значения в базе данных или в приложении является дизъюнктивной).

Способ заполнения POCO из наборов данных EF + звучит так, что это будет невозможно при использовании только EF. EF имеет несколько разрешенных шаблонов отображения, но возможности отображения нескольких таблиц в один класс POCO чрезвычайно ограничены и ограничены (если вы хотите, чтобы эти таблицы редактировались). Если вы имеете в виду просто загрузить одну сущность из EF и другую сущность из адаптера данных и просто сделать ссылку между ними, у вас должно быть все в порядке - в этом сценарии хранилище звучит как разумный шаблон, потому что цель хранилища именно в этом: загрузить или сохранить данные. Единицу работы также можно использовать, потому что вы, скорее всего, захотите повторно использовать одно соединение с базой данных между EF и адаптерами данных, чтобы избежать распределенной транзакции во время сохранения изменений. UoW будет местом, ответственным за обработку этого соединения.

Отображение EF связано с проектированием базы данных - вы можете внести некоторые объектно-ориентированные модификации, но EF все еще тесно зависит от базы данных. Если вы хотите использовать некоторую продвинутую модель домена, вам, вероятно, понадобятся отдельные классы домена, заполненные из EF и наборов данных. Опять же, ответственность за хранилище будет скрывать эти детали.

Answer 3

Из того, как много мы реализовали, я узнал следующие вещи:

1. С объектами POCO и Self Tracking трудно иметь дело, так как если у вас нет простого понимания того, что происходит внутри,Это будет неожиданное поведение, которое, возможно, сработало в вашем предыдущем проекте.
2. Изменить шаблон не так просто, так как до сих пор мы управляли простым CRUD без единицы работы и шаблона карты идентификации.Теперь большая часть устаревшего кода, который мы написали в прошлом, не учитывает эти новые шаблоны, и логика не будет работать правильно.
3. В нашем предыдущем коде мы просто использовали транзакции и один оператор вставки / обновления / удаления, который былнапрямую отправляется в базу данных, предполагая, что транзакции на стороне сервера позаботятся обо всех операциях.
4. В таких условиях мы постоянно имели дело с идентификаторами, новые сгенерированные идентификаторы были сразу доступны после одного оператора вставки, однаконе относится к EF.
5. В EF мы не имеем дело с идентификаторами, мы имеем дело со свойствами навигации, что сильно отличается от более ранних методов программирования ADO.NET.
6. Из нашего опытамы обнаружили, что только замена EF более ранним кодом доступа к данным приведет к хаосу.Но EF + RIA Services предлагает вам совершенно новое решение, в котором вы, вероятно, получите все, что вам нужно, и ваш пользовательский интерфейс очень легко с ним свяжется.Так что, если вы думаете о полном переписывании с использованием UI + RIA Services + EF, то это того стоит, потому что большая зависимость в управлении запросами автоматически уменьшается.Вы будете сосредоточены только на бизнес-логике, но это важное решение, и количество человеко-часов, необходимых для полной перезаписи или просто замены EF, практически одинаково.
7. Итак, мы пошли UI + RIA Services + EF,и мы начали заменять один модуль.В основном EF будет легко сосуществовать с вашей существующей инфраструктурой, поэтому это не повредит.