Перенос в Entity Framework пользовательский ORM

Question

В настоящее время у нас есть решение, полностью написанное от руки в ASP.NET и MVC.

В настоящее время в DAL существует множество отвратительных хаков и обходных путей, и вместо того, чтобы расширять эти хаки, мне удалось убедить масти, что нам нужно перейти на какой-то ORM.

Имея опыт работы с Entity Framework в команде, мы решили использовать Entity Framework, однако у меня есть вопрос по миграции для всех, кто мог иметь опыт работы с этим.

Будут ли проблемы с производительностью, если мы перенесем Entity-by-Entity, пока все не будет перенесено в EF? С какими возможными препятствиями (кроме очевидной необходимости переписывать большую часть BL) мы могли бы столкнуться? Должно ли это быть сделано буквально Entity-by-Entity (с точки зрения создания моделей) или возникнут проблемы с созданием модели Entity и простым изменением BL за битом.

Кажется, я не могу найти какую-либо документацию по этому вопросу ... Кажется, MSDN просто говорит: "Yay Entity Framework - это хорошо, поэтому переход на нее - это хорошо."

Любой совет будет оценен.

PS: я прочитал это: Миграция с «нативной» OODBMS на ORM (Entity Framework / SQL Server)

Однако, поскольку мы решили использовать EF вместо NHibernate, это оказалось не очень полезным.

Answer 1

Это хороший вопрос, и у меня есть ответ с моей точки зрения. Речь идет о «Yay Entity Framework - это хорошо, поэтому переход на него - это хорошо»

Теперь наша команда работает над большим (очень большим) HR SaaS-решением. С самого начала мы решили использовать:

• EF 4.1
• MySQL (это было требование от клиента)
• .NET MVC 3

Затем прошло время (около 3 недель), когда мы заметили следующее относительно EF: использование Model first неприменимо и полезно в нашей системе в случае сложной поддержки системы в будущем, когда нам нужно, например, немного изменить структуру БД или создайте новые связи между таблицами.

В этом случае мы перешли к EF Code First (с одним общим репозиторием для всех запросов к базе данных). Это был риск, потому что это такая новая технология, и в больших решениях не было лучших практик или вариантов использования. В результате мы получили много других головных болей:

• ORM сделал много запросов к базе данных (из-за большого количества связей между таблицами). Исправлено .Include ()
• Динамический прокси для объектов POCO - создал много проблем, потому что в коде первые сущности из db не похожи на запрошенный тип сущности - как динамический прокси-тип. Поэтому, когда мы попытались сериализовать их и поместить в Memcached при десериализации, мы получили ошибку, что эта сущность больше не доступна в текущем контексте. Исправлено так: http://msdn.microsoft.com/en-us/library/dd456853.aspx и это: http://blogs.dotnetkicks.com/dpeterson/2011/08/11/theres-a-proxy-in-my-boots-entity-framework-poco/
• Глупая сумка с подпиской, которая отправила много невероятных запросов. Исправлено, просмотрев нашу работу с Членством

Также мы попробовали NHibernate, чтобы просто сравнить производительность. NHiberanate имеет то же самое:)

Общая информация, которую вы должны знать об EF:

• Если вы хотите прикрепить 3-ю часть кеширования, будьте готовы к обходному пути. NHibernate имеет встроенную интеграцию этого
• Нет большой разницы между производительностью EF и Nh, но у Nh много ручной работы с отображением

Надеюсь, я отвечу на ваши квесты, и информация для вас актуальна.

ps> извините за мой английский :) 1040 *