Кто-нибудь когда-нибудь переключался между решениями ORM во время разработки?

Question

На моей текущей работе я реализовал шаблоны Repository / UoW поверх EntityFramework и DbContext. Единственные веские причины, которые я нашел для этого, могут быть, если вы не хотите зависеть от одного конкретного решения ORM. Я просто хотел узнать, делал ли кто-нибудь это когда-нибудь, и на полпути проекта (скажем, через год) решил: «Черт, я рад, что внедрил этот шаблон репозитория, потому что мне нужно переключиться с EntityFramework на NHibernate. " Помимо грубых и некоторых базовых запросов с объединениями (с использованием LINQ), я считаю, что этот дополнительный уровень абстракции раздражает, так как вам нужно создать таблицу в базе данных, написать репозиторий, написать сервис (если вы собираетесь использовать обычные 3). многоуровневая арка) и необходимый передний конец как контроллер и виды.

Обновление:

Хотелось бы узнать, есть ли у кого-нибудь ранее переключатели ORM в проекте и почему?

Answer 1

Есть много блогов Microsoft, которые предлагают использовать шаблон репозитория.

Этот поисковый запрос Google для "единицы работы структуры сущности" подтверждает это.

сущность рамки единицы работы

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

Я иногда использую хранилище BLOB-объектов Azure для хранения данных, поэтому у меня есть две реализации моего интерфейса:

IDtoEntityRepository

Я извлекаю один и тот же тип данных из двух разных хранилищ данных, и у каждого хранилища данных свои требования к работе с данными. Таким образом, я получаю реализацию 1 sql и 1 хранилище Azure BLOB. Реализация sql, случается, закодирована с помощью Entity Framework, но я мог бы легко кодировать новый код класса с помощью Telem's Orm под названием:

TelerikOrmDtoEntityRepository

Любые классы, которые были закодированы с IDtoEntityRepository, не заботятся о реализации. Делая это, я отделил все детали реализации уровня данных от вызывающего кода.

Answer 2

Просто создайте минимальные объекты, необходимые для быстрого и надежного функционального кода. После этого вы можете позаботиться о рефакторинге и т. Д., А однажды, когда вы решите сменить инструмент ORM, вы испачкаете руку, играя с механикой, такой как репозиторий и шаблоны проектирования рабочих единиц.

Кроме того, если вы уже знакомы с шаблоном репозитория, было бы неплохо предвидеть его полезность, поскольку это может позволить вам не только изменить инструмент ORM, но, возможно, использовать ADO.NET напрямую, а затем при определенных обстоятельствах. .

Я считаю, что неплохо зависеть от сторонних инструментов, таких как ORM или тому подобное, и затем я думаю, что вы хотите работать на лучшую оценку, то есть, например, NHibernate, которую я предпочитаю всем остальным Инструменты ORM, которые существуют. И это личное мнение.

Идея, о которой я говорю, заключается не в том, чтобы написать кучу классов на тот случай, если они вам когда-нибудь понадобятся. Напишите их, когда они вам действительно нужны.

Answer 3

Вам не нужно этого делать.Я не знаю ни одного проекта, который на самом деле переключился, и переключение на самом деле потребует много работы.
Если вы прочитаете блог Айенде , вы найдете множество точек против репозиториев.

Единственная причина сделать это, когда вы разрабатываете каркас, который можно использовать с несколькими ORM на основе конкретного варианта использования.

Более того, наличие репозитория на таблицу очень расточительно времени разработчика.
Даже если вы работаете с репозиториями, одного универсального репозитория с некоторыми специфичными для сущности расширениями должно быть более чем достаточно.

Сказав все это, я все еще использую репозитории, главным образом потому, что мне не нравятся прямые ссылки на третьипартийные библиотеки в несвязанном коде.Но это вопрос предпочтений, а не лучшая практика, которую я могу доказать.