Переход на ORM

Question

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

Соответствует ли это вашему опыту?
Возможно ли или даже хорошая ли идея вводить это поэтапно?
Каковы недостатки ORM?

Answer 1

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

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

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

Редактировать:исправлено имя автора

Answer 2

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

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

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

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

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

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

Answer 3

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

Answer 4

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

Answer 5

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

В остальном ORM — отличный вариант, и его обязательно стоит рассмотреть.

Answer 6

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

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

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

Answer 7

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

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

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