рефакторинг: переход с пользовательского уровня доступа к данным на Entity Framework

Question

Я разработчик .NET, и в рамках проекта по рефакторингу у меня есть несколько вопросов.

Наше программное обеспечение в настоящее время использует шаблон Active Record (однозначное соответствие между объектами данных и бизнес-объектами). Плохо то, что бизнес-объекты наследуются от объектов данных, вызывая сильную связь между уровнями.

Наша цель - перейти с нашего пользовательского уровня доступа к данным (на основе ADO.NET) на Entity Framework. У нас есть ограничение: не нарушать код, чтобы наши старые приложения по-прежнему компилировались и работали с использованием старого уровня доступа к данным, позволяя нам использовать EF для новых проектов.

Моя первая идея сделать это - сломать наследование и использовать объект данных в качестве атрибута бизнес-объекта (и использовать интерфейс или абстрактный класс для внедрения объекта данных, будь то наш пользовательский уровень или объект) Фреймворк). Свойства будут перенесены из объектов данных в бизнес-объекты, которые будут действовать как своего рода «прокси» для доступа к свойствам объектов данных.

Это было бы жизнеспособным решением? При этом все равно будет использоваться шаблон активной записи (и мне это не очень нравится, поскольку наш бизнес-уровень стал довольно большим), поэтому, если у вас есть какие-либо другие идеи, пожалуйста, не стесняйтесь.

Мой другой вопрос касается создания структуры Entity. Нам нужно, чтобы свойства сущностей имели то же имя, что и старые объекты данных (мы бы использовали абстрактный класс, чтобы бизнес-объекты могли вызывать свойства объекта данных, будь то наш пользовательский объект данных или сущности EF) , Каков наилучший способ сделать это? Использование T4 для генерации сущностей или первый подход к EF-коду?

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

Answer 1

Будет ли это жизнеспособным решением? Если бы вы начали новый проект с Entity Framework, я бы сказал: Нет. Потому что Entity Framework является реализацией репозитория и Единица работы * Шаблон 1006 * и шаблон Active Record - это совершенно другой подход.

Даже если вы используете не-POCO, EntityObject производные сущности с Entity Framework, сущности не становятся действительно активными записями, потому что функции персистентности, предоставляемые EntityObject или EntityCollection, ограничены (я полагаю, что дизайн) , EntityObject просто поддерживает отслеживание изменений, а EntityCollection имеет такие функции, как Load или CreateSourceQuery, которые поддерживают запросы к этой конкретной коллекции. Но у вас нет полной ObjectContext для выполнения произвольных запросов, удаления объектов или сохранения изменений.

EF 4.1 и DbContext даже больше не поддерживают это, поскольку EntityObject производные объекты не допускаются с DbContext. Это чистый подход POCO с персистентными неосведомленными объектами. Есть только ленивые прокси-серверы загрузки и отслеживания изменений, которые знают контекст, но это только «прозрачная» функция во время выполнения, и вы не можете программировать для этого контекста прокси.

Теперь вы не начинаете с нового проекта, но имеете архитектуру, которую вы должны уважать в больших частях. Если ваши базовые классы объектов данных (которые реализуют Active Record) имеют такие методы, как LoadMe, SaveMe, LoadCustomersContacts и т. Д., И вы используете эти методы на уровнях вашего бизнеса / сервиса, и вы не можете или не хотите менять этот слой, тогда вам, вероятно, придется найти работающий подход Active Record с Entity Framework.

Это нестандартный подход и немного противоречит архитектуре Entity Framework. Это поднимает вопросы, например: Как вы управляете созданием контекста и временем жизни относительно времени жизни объекта? Как вы справляетесь с транзакционным и нетранзакционным поведением? (SaveChanges - это отдельная транзакция, и вы не можете сохранить отдельные «строки» или сущности, вы всегда полностью сохраняете то, что находится в контексте / единице работы - измененное, добавленное или удаленное. Вероятно, это не то поведение, которое используются вашими методами Active Record с ADO.NET сегодня.)

Как это сделать? Я не знаю, я никогда не использовал этот подход. Попробуйте поискать в Google «Entity Framework и Active Record pattern» или что-то в этом роде, и, возможно, вы найдете что-то, что не говорит «Не делайте этого!».

На ваш другой вопрос: я бы предпочел DbContext с Code-First для простоты разработки (для этого он и был создан). Но имейте в виду, что есть несколько функций, которые не поддерживаются в Code-First и требуют решения на основе EDMX (я полагаю, среди прочего, «определяемые моделью функции»). Также сопоставление с хранимыми процедурами еще не поддерживается в DbContext. Вы можете выдавать необработанные операторы SQL через контекст, что может стать обходным решением для этого ограничения.

Это мой взгляд.

<ч />

Кстати: добро пожаловать в Stackoverflow! Ваш вопрос проблематичен для формата этого сайта, потому что слишком общий и немного спрашивает «мнения». Я бы порекомендовал вам разбить вашу проблему на более мелкие части и создать отдельные более мелкие и более конкретные вопросы, возможно, украшенные небольшими фрагментами кода, чтобы сделать ее более конкретной и осязаемой. Вы обычно получаете больше ответов на такие вопросы (и более ценный ответ, чем мой блабла выше). Хорошая новость: вы можете создать столько вопросов, сколько захотите.