Должны ли разработчики заботиться о возможности изменения ORM в будущем?

Question

Давайте представим, что я начинаю разрабатывать проект. Так должен ли я серьезно заботиться о возможности изменения ORM в будущем?

Или, точнее:

1. Хотите ли вы изменить ORM, который вы используете в своем текущем проекте, на другой? Если да, то каковы причины?
2. Вы когда-нибудь практиковали это? Если да, то каковы были причины?

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

Answer 1

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

Чтобы ответить на ваши вопросы:

1. Нет
2. Обычно вы меняете ORM, если инструмент, который вы используете, не удовлетворяет какую-либо существенную потребность. Я не могу придумать ни одного примера, где это имело бы смысл, - обычно вы можете обойти любые проблемы, подобные этим.

В конце дня я просто убедился бы в том, что я выбрал ORM, который будет работать для меня (не может ошибиться с чем-то вроде NHibernate), и убедился, что ваш код слабо связан, что должно гарантировать, что ваши данные код доступа изолирован. Это хорошо не только с точки зрения ремонтопригодности, но и для тестируемости.

Answer 2

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

Насколько ваши конкретные вопросы:

1. У меня есть несколько проектов, в которых используются различные системы хранения и платформы для управления данными, и было бы неплохо, если бы среди них была последовательная стратегия, но мы работаем над тем, что у нас есть время для достижения. Моим общим руководством для команд, с которыми я работаю, является выбор ORM only , если это имеет смысл для проекта, и размещение абстракций для удобства использования. Обычно я предпочитаю NHibernate (у меня больше опыта с ним), но есть много хороших решений
2. Да, я работал по крайней мере над двумя проектами, в которые мы были вовлечены, с единственной целью удаления существующих сторонних компонентов (включая платформы ORM) и замены их другими компонентами. В одном случае мы переходили от собственного ORM к NHibernate, а в другом мы переходили от ORM стороннего производителя к одному, который заказчик попросил нас разработать для них. Оба проекта были сложными и включали множество изменений, которые приложения не обрабатывали изящно. Частично это (не все) можно объяснить тем фактом, что код тесно связан с его стратегией хранения данных.