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

Я только что закончил читать статью о MSDN by John Evdemon. Он разбивает интерфейсы CRUD и называет это анти-шаблоном.

хотя я согласен с тем, что иметь что-либо stateful сложно, а Current и MoveNext-плохие идеи, я не согласен с тем, что CRUD, как в Create Read Update и Delete, плохи. Если у меня есть автосервис, и я хочу, чтобы клиенты могли делать основы, как в создании автомобиля, получить детали автомобилей, обновить детали автомобилей или удалить автомобиль, то как предназначены ли они для того, чтобы делать эти вещи без операций CRUD.

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

14
crud design-patterns soa

4 ответов

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

Edit:

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

пример:

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

16

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

5

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

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

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

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

обновление:

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

5

принятый ответ неверен. И несмотря на то, что Джон использует CRUD в качестве примера с анти-шаблоном, используя CRUD для не плохо для SOA. Вот проблема с SOA, как описывает Джон: он поощряет повышенную сложность на уровне обслуживания, что в конечном итоге приводит к меньшей поддержке нескольких вариантов использования. Одна из основных причин, по которой мы создаем 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"
  }]
}

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

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

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

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

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

0