Техника из прошлого, от которой следует отказаться

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

Создавать, читать, обновлять и удалять — так просто и так неправильно.

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

Скажи мне! Что в этом плохого?

Да конечно! Посмотрим правде в глаза с простой моделью, которая представляет RedditUser.

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

Внезапно вы вспоминаете, что посты нравятся и увеличивают Karma. Как вы реализуете эту функцию?

Как вы помните, быстро сделано с CRUD. U означает «обновление». Ваш API разработан таким образом, чтобы: PATCH api/reddituser/{id} принимать всего пользователя.

Чего ждать? Обновить только Karma и доставить весь объект RedditUser?

В чем твоя проблема? Просто доставьте проклятого пользователя.

Видеть это так тяжело, потому что кто-то должен иметь с этим дело, и это может быть ты. У вас нет возможности увидеть, какие свойства будут обновлены при вызове этой конечной точки.

Код должен всегда выражать себя наилучшим образом. Это также справедливо для API. Следовательно, используемый подход CRUD становится многословным.

Вы остаетесь с доставкой и обновлением каждого свойства.

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

Сочетание упомянутых недостатков и отсутствия масштабируемости проявляется.

Хорошо, но один слой обновления объекта может сделать это

Вы хотите изменить одно свойство.

Вы еще больше усложняете код вместо того, чтобы упростить его.

Удачи! Вам по-прежнему нужен весь объект плюс еще одно свойство, указывающее, что нужно обновить. Тогда ваша конечная точка может выглядеть примерно так:

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

Интерфейсы, основанные на задачах, — решение

Интерфейс на основе задач — отличная альтернатива.

Я уже слышу, как ты говоришь:

  • Больше методов!
  • Больше занятий!
  • Больше строк кода!
  • Больше проблем!

Итак, как это лучше? — ТВЕРДЫЙ.

Каждый метод имеет одну ответственность.

Каждый метод является мастером одной задачи.

И все они живут в гармонии, кроме того, что у них есть сниппет, который можно читать и поддерживать.

Развенчание дальнейших сомнений

1. Должен ли я всегда воздерживаться от CRUD?

Нет, CRUD хорош, если использовать его с умом.

Как и все в жизни, не злоупотребляйте и наслаждайтесь умеренно, даже World of Warcraft. CRUD API легко и быстро разрабатывать. И вы знаете, что еще нужно сделать как можно скорее. Доказательство концепции (PoC), минимально жизнеспособный продукт (MVP).

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

2. Слишком много вызовов API. Что я? Колл-центр?

Верно, и теперь вы точно знаете, что будет делать каждая конечная точка.

3. Я мог получить данные из базы данных и обработать набор изменений

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

4. Затем у меня будет конечная точка для каждого свойства.

Конечно, если это то, чего вы хотите достичь. На самом деле это другая история.

Попробуйте получить POV пользователя в вашем приложении. Какие основные варианты кто-то должен использовать? Отразите их в конечных точках. Зачем предлагать конечную точку, если RedditUser не разрешено менять свой никнейм?

Каков мой вынос, так или иначе?

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

Некоторые трудности, возникающие при простом подходе, в долгосрочной перспективе могут стать еще хуже. Следовательно, система, основанная на задачах, превосходит CRUD.

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

Want to Connect?
Get 8 long-lasting golden rules for successful developers that are your guidance through learning to code and climb the cooperate ladder.