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

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

Я работаю над проектом формы выигрыша, в котором я принял решение начать использовать entity framework 4.1 для доступа к ms sql db. База кода довольно старая, и у нас есть существующий уровень данных, который использует адаптеры данных. Эти адаптеры данных используются повсеместно (в веб-приложениях и приложениях с выигрышными формами). Мой план состоит в том, чтобы со временем заменить старый код доступа к базе данных на EF и избавиться от тесной связи между уровнями пользовательского интерфейса и уровнем данных.

Итак. Моя идея состоит в том, чтобы более или менее объединить EF с устаревшим уровнем доступа к данным и постепенно заменить устаревший уровень данных более современным подходом к вещам с использованием EF. Так что на данный момент нам нужно использовать как EF, так и устаревший код доступа к базе данных.

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

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

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

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

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

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