Переход на платформы

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

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

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

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

Книга "Robert C Martin", которая на самом деле была написана Майклом перышком ("дядя Боб" - это, кажется, фирменный знак в наши дни!) является обязательным.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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