Почему CRUD-операции настолько плохи в SOA-дизайне?

Question

Я только что закончил читать статью о MSDN Джона Эвдемона .Он разбивает интерфейсы CRUD и называет это анти-паттерном.

Хотя я согласен, что НИЧЕГО сохраняющее состояние сложно, и Current и MoveNext - плохие идеи, я не согласен, что CRUD, как в Create Read Update и Deleteплохой.Если у меня есть автосервис, и я хочу, чтобы клиенты могли выполнять основы, как в разделе «Создание автомобиля, получение сведений об автомобилях, обновление сведений об автомобиле или удаление автомобиля», как они должны это делать?без операций CRUD.

Или что мне здесь не хватает?

Answer 1

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

Edit:

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

Пример:

CRUD x Интерфейс бизнес-логики. Предположим, что вы работаете с Invoices. Каждый счет состоит из InvoiceHeader и одного или нескольких InvoiceLine. Если вы используете CRUD-интерфейс для выставления счета, вы сначала вызовете операцию CreateInvoiceHeader, чтобы создать InvoiceHeader, а затем несколько операций AddInvoiceLine, чтобы добавить все InvoiceLines - это низкоуровневый подход CRUD. Но если вы реализуете бизнес-логику на стороне службы, вы будете вызывать одиночный CreateInvoice и передавать графу сложных объектов (заголовок со всеми строками) в службу для создания и добавления того, что необходимо. Метод Create может также выполнять другие бизнес-операции, такие как запуск некоторого рабочего процесса и т. Д. Это распространенный подход SOA и распределенной системы.

Answer 2

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

<WebMethod()> _
Public Function MoveNext() As Boolean
End Function

<WebMethod()> _
Public Function Current() As Object
End Function

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

Обновление:

Нашел похожий вопрос с очень хорошим ответ :)

Answer 3

RESTfull веб-сервисы , которые в последнее время набирают популярность, доказывают неправильность поста мистера Джона Эвдемона.

Answer 4

Принят неправильный ответ.И несмотря на то, что Джон использует CRUD в качестве примера анти-паттерна, использующего CRUD для, это не плохо для SOA.Вот проблема с SOA, как описывает Джон: она способствует увеличению сложности на уровне обслуживания, что в конечном итоге приводит к меньшей поддержке нескольких вариантов использования.Одна из основных причин, по которой мы создаем API-интерфейсы, заключается в предоставлении доступа к нескольким приложениям, и именно здесь основной ROI заключается в создании API-интерфейсов.

Например, допустим, у нас есть блог API.Допустим, мы даем пользователям возможность писать посты, добавлять изображения и помещать комментарии на одном экране нашего внешнего приложения.В представлении Джона о SOA он, вероятно, порекомендовал бы, чтобы мы создали наш API, чтобы использовать один вызов для выполнения всех этих задач, чтобы он был менее разговорчивым и тому подобное ... Итак:

{
  "post_title": "New Post",
  "post_content": "Some Stuff....",
  "comments": [{
    "comment": "This is right on!",
    "userId": 101
  }, {
    "comment": "I agree.",
    "userId": 105
  }],
  "images": [{
    "imgURL": "http://some.img.com/1"
  }, {
    "imgURL": "http://some.img.com/2"
  }]
}

Теперьочевидно, это три разных объекта данных, которые необходимо хранить отдельно: пост, комментарии и изображения.С точки зрения хранилища данных сообщение отправляется в таблицу POSTS, комментарии к таблице COMMENTS и изображения к таблице IMAGES.Поэтому, если мы создаем наш сервис в соответствии с арендаторами SOA, как описывает их Джон, мы делаем один вызов с нашим объектом, и он обращается к сервисам, которые пытаются создать сообщение, которое, например, для целей, работает нормально, а затем пытается создатькомментарии, которые работают нормально, но когда мы добираемся до изображений, сервис понимает, что один из URL-адресов изображений неисправен, это ошибки.Таким образом, наш сервис возвращает ошибку?Даже если 3 другие части теперь успешно хранятся в нашем хранилище данных?Вернемся ли мы и отменить все части, которые успешно выполняются?Что, если хранилище данных уже зафиксировало изменения, и мы не можем откатить их?

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

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

Я бы сравнил эту версию SOA с недостатками, которые мы уже осознали в построении объектов Бога в объектно-ориентированном программировании.https://en.wikipedia.org/wiki/God_object

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