Перенос с LINQ на SQL в Entity Framework 4.0 - Советы, документация и т.д.

Я опробовал EF в .NET 3.5 SP1, и я был одним из тех, кто разочаровался и решил вместо этого изучить LINQ to SQL. Теперь, когда я знаю, что EF - это "выбранный" путь вперед, плюс EF 4.0 имеет некоторые интересные новые функции, я бы хотел перенести приложение в EF 4.0.

Можно ли предложить какие-либо хорошие ресурсы, специально предназначенные для миграции 4.0 и L2S? ПРИМЕЧАНИЕ. Я могу найти много блогов и статей, связанных с переносом из L2S в EF на .NET 3.5, но я чувствую, что многие из них явно были датированы и бесполезны для кого-то, использующего 4.0.

Мне бы очень хотелось, чтобы я был настолько глубоким, под капотом, как я могу получить; Я хочу действительно уйти, чувствуя, как я знаю EF 4.0, как я знаю L2S 3.5.

ТИА!

ОТВЕТЫ

Ответ 1

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

http://msdn.microsoft.com/en-us/library/ex6y04yf(VS.100).aspx

То, что я могу вам дать, - это более очевидные "gotchas". В частности, Linq2Sql хотел объединить бизнес-уровень и уровень данных намного более очевидно. Это действительно побудило вас создавать свои собственные частичные классы. Я мог бы продолжать и продолжать, но наиболее конкретная причина заключается в том, как индивидуальный картограф будет создавать общие родительские и дочерние свойства для всех отношений.

Если вы попытаетесь использовать какой-либо тип сериализации для этой модели, вам понравится запускать круглые эталонные проблемы, когда сериализатор перемещается из родительского элемента в дочерний, а затем возвращается к родительскому элементу, так как поведение сериализации Linq2Sql автоматически включает всех дочерних элементов в график. Это также может быть очень раздражающим, когда вы пытаетесь захватить запись клиента, чтобы проверить свойство "Имя" и автоматически получить все связанные записи заказов, включенные в график. Вы можете установить эти свойства родительской и дочерней навигации как "общедоступные" или "внутренние", что означает, что если вы хотите получить к ним доступ, но не хотите, чтобы сериализаторы автоматически создавали циклические ссылки, вам в значительной степени приходится обращаться к ним в частичном классы.

Как только вы начнете путь частичного класса, вы обычно просто продолжаете шаблон и, в конце концов, начнете добавлять вспомогательные методы для доступа к вашим данным в свои индивидуальные классы сущностей. Кроме того, когда Linq2Sql DataContext является более легким, вы часто находите людей, использующих какой-либо шаблон Singleton или шаблон хранилища для своего контекста. Вы не видите этого вообще с EF 3.5/4.

Итак, скажем, у вас есть среда, похожая на описанную, и вы хотите начать преобразование. Ну, вам нужно выяснить, когда ваш DataContext будет создан/уничтожен... некоторые люди начнут каждый из методов Business Layer с помощью оператора using() и позволят контексту в значительной степени жить в течение всего жизненного цикла метода. Очевидно, это означает, что вы можете столкнуться с некоторыми волосатыми ситуациями, которые требуют добавления .ToList() или какого-либо другого метода расширения к концам ваших вопросов, у вас может быть полностью собранная в памяти коллекция ваших объектов для передачи дочернему методу или что-то еще и даже то у вас могут возникнуть проблемы с попыткой обновить объекты в контексте, из которого они изначально не были извлечены.

Вам также нужно выяснить, как большая часть BusinessLogic, включенная в ваши частные классы Linq2Sql, выходит на другой уровень, если она явно не касается операций с данными. Это не будет безболезненным, поскольку вы выясните, когда вам нужен/не нужен ваш контекст, но он подходит к лучшему..

Затем вам нужно будет иметь дело с ситуацией с графиком объекта. Из-за различий в способе работы с ленивой загрузкой (они сделали это настраиваемым в EF 4.0, чтобы он больше походил на Linq2Sql для тех, кто этого хотел), вам, вероятно, потребуется проверить любые подразумеваемые использования дочерних объектов в графике из вашего Linq2Sql что он теперь не требует явного .Include() или .Load(), чтобы получить дочерние объекты в графе.

Наконец, вам нужно будет решить решение для сериализации в целом. По умолчанию атрибуты DataContracts и DataMember, которые генерируются как часть EF-модели, отлично работают с WCF, но отнюдь не великолепны с XmlSerializer, используемым для таких вещей, как старые .asmx WebServices. Даже в этом случае вы можете уйти от него, если вам никогда не понадобится сериализовать дочерние объекты по проводу. Поскольку это обычно не так, вам захочется перейти на WCF, если у вас есть более SOA, что добавит целый ряд дополнительных возможностей, но головные боли.

Чтобы справиться с ситуацией с частичными классами и сложным DataContext и даже проблемами сериализации, в EF 4.0 имеется ряд новых шаблонов генерации кода. В шаблоне POCO-Entity очень много людей, так как он создает классы POCO, как и следовало ожидать (проблема в том, что исключает любые атрибуты класса или члена для WCF и т.д. И т.д.). Кроме того, модель Self-Tracking Entities в значительной степени решает проблему контекста, потому что вы можете передавать свои сущности вокруг и позволять им помнить, когда и как они были обновлены, поэтому вы можете создавать/удалять свои контексты гораздо более свободно (например, Linq2Sql). В качестве еще одного бонуса этот шаблон является шаблоном для WCF или всего, что строится на WCF, например службах RIA или службах данных WCF, поэтому у них уже есть атрибуты [DataContract], [DataMember] и [KnownType].

Вот ссылка на шаблон POCO (не входит в комплект поставки): (EDIT: я не могу опубликовать две гиперссылки, поэтому просто посетите веб-сайт галереи visualstudio и найдите "Генератор объектов ADO.NET С# POCO" )

Обязательно прочитайте ссылку в блоге команды ADO.net об этом. Возможно, вам понравится разбиение вашего контекста и ваших объектов на отдельные проекты/сборки, если вы попадете в категорию WebService и WCF. Генерация прокси-сервера "Add Service Reference..." не использует пространства имен так же, как используется "Добавить веб-справочник...", поэтому вам может потребоваться фактически ссылаться на сборку класса объектов в вашем клиентском приложении, чтобы вы могли "исключить типы из справочных библиотек" или что-либо в ваших ссылках на службы, поэтому вы не получаете много неоднозначных ссылок от нескольких служб, которые используют одну и ту же модель EF и выставляют эти объекты...

Я знаю, что это длинный и бессвязный, но эти маленькие gotchas были для меня более важными, чем для использования context.EntityCollection.AddObject() вместо context.EntityCollection.InsertOnSubmit() и context.SaveChanges() вместо контекста .SubmitChanges()...

Ответ 2

Для кода EF Во-первых, в основном это касается обратного проектирования существующих таблиц в классы EF. EF Power Tools теперь делает это для вас:

http://msdn.microsoft.com/en-us/data/jj200620.aspx

Остальная часть - это очевидная работа по изменению существующего кода для использования этих сгенерированных классов для связи с базой данных вместо LINQ to SQL.

Ответ 3

Я нашел этот шаблон преобразования, он для бета1 (2010). Кажется, что нет более новой версии. Mabe вы можете изменить его для работы с RTM.

Не использовал его сам.