Переход на ORM

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

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

ORM должен быть разработан для уменьшения шаблонного кода. Время / проблемы и рентабельность инвестиций зависит от вас :)

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

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

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

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

Обновлено: исправлено имя автора

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

Помимо этого, ORM - отличный способ, и его обязательно стоит рассмотреть.

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

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

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

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

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

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

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

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

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

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