Мигрируя от LINQ до SQL к Платформе Объекта 4.0 - Подсказки, Документация, и т.д.

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

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

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

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

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

Итак, допустим, у вас есть некоторая среда, аналогичная описанной, и вы хотите начать преобразование. Что ж, вам нужно выяснить, когда ваш DataContext будет создан / уничтожен ... некоторые люди просто запускают каждый метод бизнес-уровня с помощью оператора 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 () ...