Пора внедрять ORM в вашу систему
Это нужно было сделать давно. Ровно тогда, когда вы поняли, что будете работать с базой данных. Сейчас, конечно, внедрить ORM сложнее, чем на старте, но всё ещё не поздно.
Сегодня я буду навязывать своё субъективное, однобокое и единственно правильное мнение, зачем вам нужен ORM и что вы от него получите в перспективах разной дальности горизонтов.
Для внедрения ORM в вашем проекте существуют противопоказания. Проконсультируйтесь со здравым смыслом перед применением.
Пьянящее чувство полезности
Да, это офигенно. Вы начали проект, который давно нужен был бизнесу. Не просто пет-проект, не какая-то там курсовая, а самый настоящий проект для бизнеса за деньги. Чтобы вылечить самые больные проблемы, которые накапливались у бизнеса годами. Вы решились помочь людям, которые страдают от несовершенства технологий каждый день.
Мы, айтишники, просто волшебники. Мы можем это сделать. Особенно, когда горят глаза и чешутся руки. Это же так заманчиво — потратить день на разработку, чтобы потом десятки людей экономили своё время каждый день. Каждый божий день. Мы будем давно уже делать другие полезные вещи, а те самые люди всё ещё будут экономить своё время. И радоваться.
Расслабьтесь, котаны, здесь не будет «спусканий на землю» или чего-то подобного. Мы действительно так можем. Нам поэтому так много и платят. Именно поэтому нам эта работа так нравится. Да, а ещё мы получаем удовольствие от того, что делаем полезные штуки. Нам хорошо, когда мы полезные, когда нас ценят. Дофамин, серотонин, все дела (я просто не разбираюсь в этом, поставил пару умных слов).
Это действительно пьянящее чувство, когда ты берёшься за то дело, которое получается. Ты приносишь реальную пользу. Ты спасаешь целый бизнес, весь в белом пальто. Тебе приходит фидбэк, насколько хорошо стало. Это греет. Это мотивирует.
Ну почти хорошо. Вот если бы ещё это и это поправить. Вот тут автоматизировать. Вот тут ещё в экселе работают. Бизнес, почуяв запах крови оптимизации, захочет больше. Ещё больше. Ещё!
Всё. С этого момента вы официально белки в колесе. Или хомячки, кому какая аналогия больше нравится. Бизнес будет от вас требовать всё больше и больше. Вы сделаете сложное — захотят нереальное. Сделаете нереальное — захотят невозможное. У бизнеса нет кнопки «стоп», у вашего приложения нет предела возможностей. Есть вы, есть бизнес, есть приложение.
Сложность
С каждой внедрённой фичей сложность приложения растёт. Каждый раз, когда делается новая фича, приходится учитывать, а не поломает ли это старые фичи. А ещё становится всё сложнее и сложнее держать все нюансы в голове.
Тем временем бизнес входит во вкус. Бизнес чувствует раж. Он знает, что команда может сделать сложное и хочет ещё сложнее. А у вашей команды с каждой итерацией колеса сложность возрастает. Уже нет эффекта «низкой базы» и каждое новое нововведение даётся если не с кровью, то с потом. В этом фундаментальная проблема взаимодействия бизнеса и команды разработки.
Сложность — это ваш враг. Наш, простите. Также это враг и бизнеса, потому что это и его проблема. Только ему очень сложно это объяснить. Он своими глазами видел, как может преобразить процессы ваша информационная система. Вы можете попробовать, но, скорее всего, у вас ничего не получится. Я не буду давать советов тут, выкручивайтесь сами.
Вы уже сидите на игле дофамина. Вам жизненно необходимо увеличивать дозу полезности бизнеса, потому что он тоже сидит на той же игле. А тут эта херня — сложность. Которая всё портит.
Я не скажу, как со всем этим справиться. Я расскажу, как немного снизить сложность системы за счёт внедрения ORM, чтобы хоть чуть продлить вам кайф, наркоманы.
Данные
Первое, что приходит в голову при разработке системы: как хранить данные. «База данных» ответ. Не, ну серьёзно, а что ещё? Какая? Ну просто база данных, любая. Чтоб данные хранила. Ну не в экселе же хранить, серьёзно. Берём {vendorname}sql.
Итак, вы выбрали реляционную базу данных. Всмысле, вы не выбирали именно реляционную, вы вообще не думали про слово «реляционная», вам оно не было нужно. Но выбрали.
Так, для тех, кто выбрал NoSql небольшая приписка: вы ещё пожалеете. Вы ещё переделаете свою базу под RDBMS, а потом, когда уже всё переделаете, поймёте, для чего нужна была NoSQL. И переделаете часть на монгу. Или что там модно.
У вас реляционная база данных и объектно-ориентированный язык для работы с этими данными. Чувствуете, какое назревает противоречие?
Сейчас для котят на пальцах: объектно-ориентированные данные хранят объекты внутри объектов. Реляционные ссылаются.
Я вот раньше думал и пропагандировал мысль, что ORM именно это и значит — мостик между реляционной моделью и объектно-ориентированной. Как-бы не так. То есть да. Ну почти. Дело в том, что это не решаемая для общего случая проблема. А в частных случаях фетчить данные и раскладывать по полям — ну наверное вы это умеете. Иначе, что вы тут вообще делаете?
Сделать привязку один раз руками не проблема. Проблема потом поддерживать соответствие. А ещё более суровая проблема — быть уверенным, что соответствие поддерживается.
ORM
ORM нужен, чтобы в базе данных и коде была одна модель. Чтобы поля класса соответствовали колонкам таблицы и всё кастилось волшебством само. Чтобы можно было работать с объектами, как будто они вовсе не из базы данных, а просто сидели тут, в приложении.
ORM нужен, чтобы данные и приложение были одним целым. Чтобы не было разницы в коде между объектом из словаря и из репозитория. Потому что тебе, дорогой котофей, нужно управлять сложностью. А чем меньше сложности, тем легче фичи и тем больше дофамина, мы же помним?
ORM нужен, чтобы ты не работал больше с полями. Серьёзно, не надо. Хватит уже. Поля в базе — это поля в базе, а вы всей командой работаете бизнес-логикой, которая не ограничивается одним полем. Нет, конечно, уровнем объектов тоже не ограничивается. Но давайте хотя бы с полями покончим, уже меньше будет проблем, ок?
Хватит писать логику в базе данных
Хватит. Правда. Вы не сможете развивать сколько-нибудь сложную систему на основе встроенных в базу данных языков. Как бы вы ни старались, вы всё равно будете работать с данными, а не с доменными сущностями. Вы всегда будете на ступень-две ниже тех, кто работает с объектами.
Фундаментальная проблема pl/sql-type языков — они write only. Да, это приходит только с возрастанием сложности, простые конструкции не вызывают подозрений. Тут та же ситуация, что с лягушкой. Как со всеми нами. Сложность вырастает, она мешает, но внутри базы данных сложность становится проблемой быстрее.
Работайте продуктивнее в языке общего назначения, с возрастанием сложности у вас будет больше возможностей этой сложностью управлять. Ну там интерфейсы всякие, наследование, инкапсуляция, готовые библиотечки с гитхаба.
Если вы пишете логику в базе данных с применением языка общего назначения, то ответьте на вопрос:, а как вы это объединять будете? Вот хотя бы себе, но честно.
Я знаю, что есть разработчики, которые прекрасно знают, чего они хотят добиться логикой внутри БД, у которых всё хорошо и оправдано. Но они нас покинули ещё на втором абзаце. Вы-то зачем?
Перестаньте руками писать запросы. Это быстрее в моменте, но когда ваша система станет чуть сложней, вам эти запросы придётся править. Каждый раз править. На каждое добавленное поле придётся дорабатывать код фетча.
Конечно, вы всегда можете автоматизировать процесс. Вы можете сделать кодогенератор или синхронизатор схемы БД, распарсив класс данных в синтаксисе своего языка и замапив типы данных. Но это же и будет ORM. Простой, кривой, ещё маленький. Может быть оно так и надо. Может быть таков путь.
Пора внедрять ORM в вашу систему
Habrahabr.ru прочитано 3178 раз
