爲什麼在SOA設計中CRUD操作如此糟糕？

我剛讀完MSDN by John Evdemon的文章。他將CRUD界面打亂並稱之爲反模式。爲什麼在SOA設計中CRUD操作如此糟糕？

雖然我同意擁有任何有狀態是困難的，Current和MoveNext是不好的想法，但我不同意在創建讀取更新和刪除中的CRUD不好。如果我有汽車服務，並且希望讓客戶能夠做到這些基礎知識，例如創建汽車，獲取汽車細節，更新汽車細節或刪除汽車，那麼他們如何才能做到這些事情沒有CRUD操作。

或者我在這裏錯過了什麼？

來源

2010-10-14 uriDium

我想我得閱讀文章得到了答案：因爲是當光標操縱（MOVENEXT）視爲一個CRUD操作？ – mikemanne 2010-10-14 13:09:44

的CRUD接口應在分佈式系統/ SOA方案來避免，因爲他們都非常健談。但是，並不意味着必須。當你有一些客戶動作需要多次調用你的服務時，你就會知道你應該放棄CRUD方法並創建新的服務操作，這些操作會將這些調用集中到一次調用中。在設計分佈式系統時，應始終將呼叫次數降至最低，因爲網絡呼叫非常耗時。

編輯：

你可以考慮一下CRUD接口有關的服務所公開的數據訪問。有時你真的想要這樣。但是在SOA和分佈式系統架構中，通常會公開業務功能，這些業務功能已經包裝了數據訪問並提供了更復雜的操作（彙總了許多數據訪問操作）。

實施例：

CRUD X商業邏輯接口。假設您正在使用Invoices。每張發票由InvoiceHeader和一個或多個InvoiceLine組成。如果您使用CRUD界面作爲發票，您將首先調用CreateInvoiceHeader操作創建InvoiceHeader，然後再添加幾個AddInvoiceLine操作以添加所有InvoiceLines - 即低級別CRUD方法。但是，如果您在服務端實現業務邏輯，您將調用單個CreateInvoice並將複雜的對象圖（包含所有行的標題）傳遞給該服務以創建並添加所需的內容。方法Create也可以做其他業務操作，如啓動一些工作流程等。這是常見的SOA和分佈式系統方法。

來源

2010-10-14 09:17:11

讓我困惑了一下。如果我們不公開CRUD操作，我們如何讓客戶創建新實體或更新他們的詳細信息。例如只需一個簡單的Create方法即可接受汽車。如果有問題，我們會發回故障。如果你什麼都得不到，那麼它是成功的。在我看來，它不會變得不那麼健談。就像我說過的，我可能會在這裏錯過一些大事。 – uriDium 2010-10-14 09:28:43

@uriDium：我加了一些例子。 – 2010-10-14 09:35:55

哦對。感謝這個例子。因此，CRUD幾乎是一種「真正的形式」，一切都分解爲基本的創建讀取更新或刪除是一個壞主意，因爲它強制提供健談的服務。如果您可以將它們全部包裝在單一服務方法中，例如PlaceOrder（invoiceHeader，List ）會更好，因爲它減少了聊天並提高了商業意識。但是，顯然還有一種情況，我們可能只需要創建一個對象。我明白了嗎？ – uriDium 2010-10-14 09:42:30

RESTfull web services最近越來越受歡迎被證明是錯誤的先生約翰Evdemon的職位。

來源

2010-10-14 09:10:14

我不這麼認爲，他說：「開發者在開發自己的模式之前應該諮詢現有的行業標準。」那麼HTTP與它的CRUD操作是你使用RESTfull Web服務的標準。恕我直言是這裏的故事，它是沒有意義的定義你自己的CRUD操作CRUD操作的原因有足夠的解決方案已經發明。 – Stephan 2011-09-07 08:54:34

我認爲他有故意設計了這裏最糟糕的接口，它不是一個真正的CRUD接口。

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

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

這兩種方法顯然不是無狀態的，但它們也不需要真正的CRUD接口。我認爲這只是一個寫得很差的例子，它與CRUD操作並不真正相關。

更新：

發現了類似的問題，有一個非常好的answer :)

來源

2010-10-14 09:12:26 willcodejavaforfood

接受的答案不正確。儘管John使用CRUD作爲使用CRUD的反模式示例，但對於SOA並不壞。正如John所描述的，SOA的問題在於：它會增加服務級別的複雜性，最終導致對多個用例的支持減少。我們構建API的主要原因之一是提供對多個應用程序的訪問，這是主要投資回報率構建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租戶來構建我們的服務，那麼我們只需要使用我們的對象進行一次調用，然後它就會嘗試創建帖子的服務，例如，它的工作很好，然後嘗試創建評論哪些工作正常，但當我們到達圖像的服務意識到，其中一個圖像網址有問題是失敗的。那麼我們的服務返回失敗？儘管現在3個其他部分已成功存儲在我們的數據存儲中？我們回去撤銷所有成功執行的部分嗎？如果數據存儲已經提交了更改，而我們不能將其還原？

的事實夫婦這樣，如果我們就做它「更健談」，並提交其個人，我們現在可以重新使用在其他應用程序的服務，而無需重新編寫該服務的任何部分。

綜合服務的壞的部分是，你正在上的想法，服務應該永遠不會失敗...這是荒謬的銷售。總有一種情況會出現失敗，並且將所有內容整合到一項服務中，這會增加您的複雜性，並增加您的失敗能力。

我這個版本的SOA的比較，我們已經在面向對象編程建立神的對象實現的缺點。 https://en.wikipedia.org/wiki/God_object

我們知道比這使我們爲什麼要老調重彈的更好？與God Objects一樣，合併或上帝服務是一個糟糕的主意。我說要建立你的服務來做一件事，儘可能多地使用你的服務，你的服務會很好。

來源

2015-07-14 16:52:26 Cleanshooter

爲什麼在SOA設計中CRUD操作如此糟糕？

回答

相關問題