Самодельная модель SQL против ORM?

Я читал обсуждение Stack Overflow о преимуществах и недостатках ORM, и есть разные мнения. Я хотел бы описать этот конкретный случай.

  • Среднемасштабируемое веб-приложение на основе LAMP с небольшим количеством спагетти-кода внутри.
  • Код весьма далек от ООП, хотя есть контроллеры со встроенными шаблонами и ветвь слабых классов моделей.
  • Есть несколько десятков таблиц MySQL и около тысячи файлов.
  • Кэширование, настроенное на выполнение MySQL-запросов с указателями.
  • Около миллиона просмотров в месяц.
  • Пользователи в основном имеют доступ для чтения.

У меня такой вопрос:

Стоит ли реализовывать ORM (Doctrine2 или Propel), или я должен ограничиться написанием классов моделей с нуля (аналогично шаблону ActiveRecord, группируйте методы / запросы по таблице и записи, чтобы каждый объект имеет два связанных класса)?

Основные цели:

  1. производительность приложения,

  2. простота чтения и модификации кода / запросов, а также

  3. легкость возможной модификации БД (деталей).

Лично я предпочитаю второй вариант; есть довольно сложные SQL-запросы, я сомневаюсь, что ORM сможет поддерживать абстракцию БД для всех запросов. Начальная разработка закончена, и нет необходимости в быстрой разработке кода / кода запроса. Для нас гораздо важнее уметь легко читать, понимать и изменять код / ​​запросы.

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


web-applications refactoring orm lamp
person Parap    schedule 06.10.2011    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Структурирование кода определенно поможет вам с 2 и 3, и, если все сделано правильно, 1 тоже не пострадает. Поскольку вы включаете сторонние ORM, должно быть легче достичь хорошей производительности, поскольку эти функции ORM поддерживают такие функции, как кэширование и ленивая загрузка «из коробки».

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

Я бы сказал, что хороший способ использования стороннего ORM - это организовать ваш существующий код и запросы аналогичным образом. Итак, вы можете ввести класс ProductRepository, в котором есть метод find (), инкапсулирующий существующий запрос и возвращающий ResultSet. Затем вы должны ввести класс данных продукта (класс только с полями и без методов). Класс продукта должен отображать таблицу Product в базе данных. Теперь find должен вернуть массив продуктов. Метод find () теперь сначала преобразует ResultSet в массив продуктов и вернет массив. Код клиента следует соответствующим образом изменить. Наконец, вы начинаете заменять свои пользовательские запросы внутри метода find () делегированием в ORM. Клиенты, использующие репозиторий, не должны обнаруживать изменения. Класс данных о продукте - это начальная часть слоя вашей модели. По мере продвижения вы можете добавить к нему поведение и создать реальный слой домена.

Возвращаясь к вашему вопросу, я бы сказал, что вы сначала группируете свой существующий код в форме настраиваемой Active Record (я предлагаю репозиторий, но, в конце концов, это просто вопрос организации), а затем вы вводите ORM. Итак, это не ситуация «либо-либо», а первый и второй этап рефакторинга.

Я бы подошел к этому следующим образом:

  1. Сначала напишите несколько автоматических тестов
  2. Попробуйте разделить код на разные уровни: представление, домен, постоянство.
  3. Выполните рефакторинг, как описано в предыдущем разделе.

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

Я достаточно подробно описал этот подход в своей книге «Профессиональный рефакторинг в C #», и вы можете загрузить образец кода, который проведет вас через здесь.

person Danijel Arsenovski    schedule 26.07.2012