Я сделал множество таких преобразований и FWIW, я бы сказал, что есть больше сходств, чем различий. Я не думаю, что есть какая-то определенная документация, которая поможет вам почувствовать себя экспертом в EF4, помимо того, что уже есть ...
http://msdn.microsoft.com/en-us/library/ex6y04yf(VS.100).aspx
То, что я могу вам дать, - это более очевидные "ошибки". В частности, 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 Services или WCF Data Services, поэтому у них уже есть атрибуты [DataContract], [DataMember] и [KnownType].
Вот ссылка на шаблон POCO (не входит в комплект поставки):
(РЕДАКТИРОВАТЬ: я не могу опубликовать две гиперссылки, поэтому просто посетите веб-сайт галереи visualstudio и найдите «ADO.NET C # POCO Entity Generator»)
Обязательно прочитайте ссылку в блоге команды ADO.net о реализации этого. Вам может понравиться разделить ваш контекст и ваши сущности на отдельные проекты / сборки, если вы попадаете в категорию WebService vs. WCF Service. Генерация прокси «Добавить ссылку на службу ...» не делает пространства имен таким же образом, как раньше, «Добавить ссылку на веб-сайт ...», поэтому вы можете ссылаться на сборку класса сущностей в своем клиентском приложении, чтобы вы могли «исключить» типы из справочных библиотек "или что-то еще в ссылках на ваши службы, поэтому вы не получите много неоднозначных ссылок от нескольких служб, которые используют одну и ту же модель EF и раскрывают эти сущности ...
Я знаю, что это долго и беспорядочно, но эти маленькие ошибки стали для меня больше проблемой, чем не забывать использовать context.EntityCollection.AddObject () вместо context.EntityCollection.InsertOnSubmit () и context.SaveChanges () вместо context.SubmitChanges () ...