ORM или SQL в большом, масштабируемом и обслуживаемом веб-приложении?

Question

Я знаю, что в Интернете уже есть много сообщений на эту тему.

Однако многие люди склонны концентрироваться на разных вещах, когда говорят об этом. Моя главная цель - создать масштабируемое веб-приложение, которое легко обслуживать. Скорость, с которой я развиваю и поддерживаю, гораздо более ценится мной, чем сырая производительность (или я мог бы использовать вместо нее Java).

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

Тогда я понял, что мне нужно правильно структурировать и кодировать. Я начал использовать CodeIgniter. Это действительно дало мне структуру и поддерживаемый код. Многие пользователи говорят, что фреймворки замедляют работу, но я думаю, что они упустили картину. Код должен быть легко обслуживаемым и понятным.

Framework + OOP + MVC сделали мое веб-приложение настолько структурированным, что добавление функций больше не было проблемой.

Когда я создаю модель, я склонен думать, что она представляет объект данных. Может быть, форма или даже таблица / база данных. Вот я и подумал об ORM (доктрине). Может быть, это будет еще одна отличная реализация в моем веб-приложении, придающая ему большую структуру, чтобы я мог сосредоточиться на функциях, а не повторяться.

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

Итак, теперь я прошу всех вас, ребята, которые, как и я, стремятся к поддерживаемому коду и знают, насколько это важно, ORM (доктрина) необходимо иметь для поддерживаемого кода, как framework + mvc + oop?

Мне нужно больше советов по жизненному опыту, чем по советам «raw sql is fast», потому что если бы я заботился только о сырой производительности, я бы сначала отбросил framework + mvc + oop и продолжал жить в кошмаре кодирования.

Такое ощущение, что он так хорошо вписывается в среду MVC, где модели - это таблицы.

Сейчас у меня 150 запросов sql в одном файле, выполняющих такие простые вещи, как получение записи по идентификатору, получение записи по имени, получение записи по электронной почте, получение записи по X и так далее. Я думал, что ORM может уменьшить эти строки, или я уверен, что в будущем это увеличится до 1000 кв. И если я изменяю в одном столбце, я должен изменить их все! какой страшный сон снова только думать об этом. И, возможно, это также может дать мне хорошие модели, которые соответствуют шаблону MVC.

Является ли ORM правильным решением для структурирования и сопровождения кода?

Answer 1

Ajsie,

Мой голос за ОРМ. Я использую NHibernate. Это не идеально, и есть значительная кривая обучения. Но код гораздо проще в обслуживании, гораздо больше ООП. Почти невозможно создать приложение с использованием ООП без ORM, если вам не нравится много дублирующегося кода. Это определенно устранит, вероятно, подавляющее большинство кода SQL.

А вот и другое. Если вы собираетесь построить систему ООП, вы все равно будете писать свой собственный O / R Mapper. Вам нужно будет вызывать динамический SQL или хранимые процессы, получать данные в виде читателя или набора данных, преобразовывать их в объект, связывать отношения с другими объектами, превращать модификации объекта в вставки / обновления SQL и т. Д. То, что вы напишите, будет медленнее и более глючит, чем NHibernate или что-то, что уже давно на рынке.

Ваш единственный выбор - создать процедурное приложение, ориентированное на данные. Да, это может работать быстрее в некоторых областях. Я согласен, что производительность важна. Но важно то, что это достаточно быстро. Если вы сэкономите несколько миллисекунд здесь и там, выполняя процедурный код, ваши пользователи не заметят повышения производительности. Но вы заметите дерьмовый код.

Самым большим узким местом в ORM является правильный способ предварительной выборки и отложенной загрузки объектов. Это входит в проблемы n-запроса с ORM. Тем не менее, они легко решаются. Вам просто нужно настроить производительность ваших объектных запросов и ограничить количество обращений к базе данных, указать, когда следует использовать объединения и т. Д. NHibernate также поддерживает богатый механизм кэширования, чтобы вы не обращались к базе данных вообще время от времени.

Я также не согласен с теми, кто говорит, что производительность связана с пользователями, а обслуживание - с программистами. Если ваш код не легко поддерживается, он будет содержать ошибки и будет медленно добавлять функции. Ваши пользователи позаботятся об этом.

Я не буду говорить, что каждое приложение должно иметь ORM, но я думаю, что большинство из них выиграют. Также не бойтесь использовать собственный SQL или хранимые процедуры с ORM время от времени, где это необходимо. Если вам необходимо выполнить пакетное обновление миллионов записей или написать очень сложный отчет (будем надеяться на отдельную денормализованную базу данных отчетов), тогда вам следует использовать прямой SQL. Используйте ORM для ООП, транзакционной, бизнес-логики и C.R.U.D. и используйте SQL для исключений и крайних случаев.

Я бы порекомендовал прочесть материал Джеффри Палермо по NHibernate и Onion Architecture. Кроме того, возьмите его проворный учебный лагерь или другие классы, чтобы изучить O / R Mapping, NHibernate и OOP. Вот что мы используем: NHibernate, MVC, TDD, Dependency Injection.

Answer 2

Многие пользователи говорят, что фреймворки замедление, но я думаю, что они пропустил большую картину. Код ДОЛЖЕН БЫТЬ ОБСЛУЖИВАННЫМИ И ЛЕГКИМИ К ПОНЯТЬ.

Хорошо структурированная, легко обслуживаемая система бесполезна, если ее производительность - это Suh Suck!

Удобство обслуживания - это то, что приносит пользу программистам, которые создают приложение. Сырая производительность приносит пользу реальным людям, которые используют приложение для своей работы (или чего-то еще). Итак, чьи заботы должны быть первостепенными: те, кто строит систему, или те, кто за нее платит?

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

Answer 3

Я начал развиваться, как ты, без инструментов orm.

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

Но я также видел недостатки этих инструментов: очень низкая производительность. Но в основном это были злоупотребления инструментом (в этом случае спящий режим).

Orm - очень сложный инструмент, поэтому ими легко злоупотреблять, но если у вас есть опыт работы с ними, вы сможете получить почти те же характеристики, что и в raw sql. Я хотел бы получить три совета для вас:

• Если производительность не критична, используйте инструмент orm (выберите хороший, я не разрабатываю с php, поэтому не могу дать вам имя)
• Обязательно для каждой добавляемой вами функции проверяйте sql, который инструмент orm создает и отправляет в базу данных (например, благодаря средству ведения журнала). Подумайте, так ли вы написали свои запросы. Большая часть неэффективности инструментов orm связана с нежелательными данными, которые собираются из базы данных, уникальными запросами, разделенными на несколько, и т. Д. Медлительность редко возникает из-за самого инструмента
• Не используйте инструмент для всего. Выбирайте разумно, когда его не использовать (вы уменьшаете удобство обслуживания каждый раз, когда делаете доступ к сырой базе данных), но иногда это не просто попытка заставить инструмент orm сделать то, для чего он не был разработан.

Edit: Орм инструмент наиболее полезен при очень сложной модели: множество связей между сущностями. Что чаще всего встречается в конфигурационной части приложения или в сложной бизнес-части приложения. Так что это менее полезно, если у вас есть только несколько сущностей, и если есть меньше шансов, что они будут изменены (реорганизованы).

Предел между несколькими сущностями и многими неясен. Я бы сказал, что более 50 различных типов (таблиц sql, без таблиц соединений) много, а меньше 10 - мало.

Я не знаю, что использовалось для создания стекового потока, но, должно быть, раньше он был очень тщательно протестирован на производительность.

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

Answer 4

Очень важно иметь высокую работоспособность. Я разработал крупномасштабное веб-приложение с низкоуровневой сверхвысокой производительностью. Большим недостатком было поддержание системы, то есть разработка новых функций. Если вы хотите медленной разработки, клиенты будут искать другие системы / приложения. Большинство ормов имеют функции, если вам нужно делать optmized запросы непосредственно в SQL. Сама форма не является узким местом. Скажу больше о хорошем дизайне БД.

Answer 5

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

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