Переход на ORM

Я настоятельно рекомендую приобрести копию книги Майкла Фезера Работаем эффективно с Устаревший код (под "Устаревшим кодом" Feathers подразумевается любая система, которая недостаточно охвачена модульными тестами). Он полон хороших идей, которые должны помочь вам с рефакторингом и поэтапным внедрением лучших практик.

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

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

Изменить: исправлено имя автора

Книга «Роберт С. Мартин», которую на самом деле написал Майкл Фезерс («Дядя Боб», кажется, в наши дни является торговой маркой!), обязательна.

Практически невозможно — не говоря уже о безумно трудоемких — поместить модульные тесты в приложение, разработанное без них. Код просто не будет поддаваться.

Но это не проблема. Рефакторинг заключается в изменении дизайна без изменения функции (надеюсь, я не слишком сильно исказил смысл), поэтому вы можете работать в гораздо более широкой манере.

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

Теперь можно приступать к рефакторингу. Вы хотите начать извлекать свой код доступа к данным, чтобы его можно было заменить функциональностью ORM, не слишком беспокоя. Часто тестируйте: с устаревшими приложениями вы удивитесь, что сломается; сплоченность и связь редко бывают такими, какими они могли бы быть.

Я бы также рассмотрел статью Мартина Фаулера Рефакторинг , что, очевидно, является окончательной работой над процессом.

Я работаю над большим приложением ASP.net, где мы недавно начали использовать NHibernate. Вместо этого мы переместили большое количество объектов домена, которые мы сохраняли вручную, на Sql Server в NHibernate. Это немного упростило вещи и значительно облегчило изменение вещей с течением времени. Мы рады, что внесли изменения и используем NHibernate там, где это уместно, для большей части нашей новой работы.

Я слышал, что TypeMock часто используется для рефакторинга устаревшего кода.

Я серьезно думаю, что введение ORM в унаследованное приложение вызывает проблемы (и может быть такой же проблемой, как и полное переписывание).

Помимо этого, ORM — отличный способ, и его определенно следует рассмотреть.

Правило рефакторинга таково. Делайте модульные тесты.

Так что, возможно, сначала вам следует разместить несколько юнит-тестов, по крайней мере, для основных/основных вещей.

ORM должен быть разработан для сокращения стандартного кода. Время/затраты по сравнению с ROI для предприимчивости зависит от вас :)

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

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

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