Ответ 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()...