Dlaczego operacje CRUD są tak złe w projekcie SOA?

RESTfull Web services , które ostatnio zyskują na popularności, okazuje się błędnym wpisem Pana Johna Evdemona.

Myślę, że celowo zaprojektował najgorszy możliwy interfejs tutaj i tak naprawdę nie jest to interfejs CRUD.

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

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

Te dwie metody nie są oczywiście bezpaństwowe, ale nie są też potrzebne do prawdziwego interfejsu CRUD. Myślę, że to tylko bardzo słabo napisany przykład i nie jest tak naprawdę związany z operacjami CRUD.

Update:

Znalazłem podobne pytanie z bardzo dobrą odpowiedź :)

Przyjęta odpowiedź jest nieprawidłowa. I pomimo faktu, że John używa CRUD jako anty-wzór przykład za pomocą CRUD for nie są złe dla SOA. Oto problem z SOA, jak opisuje John: zachęca do zwiększenia złożoności na poziomie usług, co ostatecznie prowadzi do zmniejszenia wsparcia dla wielu przypadków użycia. Jednym z głównych powodów, dla których tworzymy interfejsy API, jest zapewnienie dostępu do wielu aplikacji.

Na przykład powiedzmy, że mamy bloga API. Powiedzmy, że dajemy użytkownikom możliwość pisania postów, dodawania zdjęć i umieszczania komentarzy na jednym ekranie naszej zewnętrznej aplikacji. W wizji Johna SOA prawdopodobnie zaleciłby, abyśmy zbudowali nasze API, aby używać jednego wywołania do robienia wszystkich tych rzeczy, więc byłoby to mniej gadatliwe i bla bla bla... więc:

{
  "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"
  }]
}

Teraz są oczywiście trzy różne obiekty danych, które muszą być oddzielnie przechowywane tutaj: post, komentarze i obrazy. Z perspektywy magazynu danych post przechodzi do tabeli posty komentarze do tabeli komentarze i obrazy do tabeli obrazy. Więc jeśli budujemy naszą usługę po najemców SOA, jak opisuje je John, wykonujemy nasze jedno połączenie z naszym obiektem i idzie do usług, które próbują stworzyć post, który, na przykład, działa dobrze, to próbuje stworzyć komentarze, które działają dobrze, ale kiedy dojdziemy do obrazów usługa zdaje sobie sprawę, że jeden z adresów URL obrazu jest uszkodzony są nie. Więc nasze serwis zwraca awarię? Nawet jeśli 3 Inne części są teraz z powodzeniem przechowywane w naszym magazynie danych? Czy cofamy i cofamy wszystkie części, które wykonują się pomyślnie? Co jeśli magazyn danych już wprowadził zmiany, a my nie możemy ich cofnąć?

Połącz to z faktem, że gdybyśmy uczynili go "bardziej rozmownym" i złożyli je indywidualnie, moglibyśmy teraz ponownie korzystać z tych usług w innych aplikacjach bez konieczności ponownego pisania jakiejkolwiek części usługi.

The bad part of the usługi skonsolidowane polega na tym, że jesteś sprzedawany z myślą, że usługa nigdy nie powinna zawieść... co jest śmieszne. Zawsze będzie przypadek krawędzi, gdzie coś się nie powiedzie i konsolidując wszystko w jednej usłudze zwiększyłeś swoją złożoność i faktycznie zwiększyłeś swoją zdolność do niepowodzenia.

Porównałbym tę wersję SOA do niedociągnięć, które już zdaliśmy sobie sprawę w budowaniu obiektów Boga w programowaniu obiektowym. https://en.wikipedia.org/wiki/God_object

Wiemy lepiej niż to, więc dlaczego go ponownie? Consolidated lub God Services są złym pomysłem, tak jak Bóg obiektów. Mówię, zbuduj swoje usługi, aby zrobić jedną rzecz i zrobić to dobrze dla tak wielu przypadków użycia, jak możesz, a Twoja usługa będzie dobra.