設計一個API：使用數據層對象還是複製/複製？

重寫一個基於web的應用程序;我願做這樣的方式：

所有交易都要經過一個Web服務API（類似http://api.myapplication.com），使客戶可以與他們的數據工作我們做的/一切，他們可以通過我們提供的web界面做同樣的方式，他們還可以做編程
類庫作爲一個數據層（SQL +實體框架），爲一對夫婦設計的原因，都沒有涉及這個問題

問題是，如果我選擇不暴露實體框架對象救援人員到場呃Web服務，重新創建實體框架對象的「API」版本，然後編寫所有「代理」代碼來複制屬性是很多工作。

這裏最好的做法是什麼？吸取它併爲每個對象創建一個API模型類，或只使用實體框架版本？

任何捷徑這裏從那些你們誰一直沿着這條道路和查處版本/向後兼容，其他頭痛？

編輯：反饋後，讓更多的意義可能是：

2011-02-25 Brandon

順便說一句，「我們使用自己的Web服務」背後的想法是，如果做出影響客戶應用程序的決定，我們也會感到痛苦......好主意？ – Brandon 2011-02-25 18:16:58

爲您的應用程序使用與提供給客戶相同的服務層是很好的，但是您應該直接使用它（直接調用服務方法），而無需WCF傳輸。 – 2011-02-25 18:20:52

只是爲了闡述一點：WCF在每個請求周圍添加了大量額外的「包裝」。通過強制你的網站不斷創建這個包裝並通過網絡發送它可以大大增加你的內部網絡流量，並因此人爲地降低你的機器的可用性。這是毫無意義的，而且通常是不被接受的。 – NotMe 2011-02-25 18:33:03

我不會通過API的Web服務接口發佈網站數據。這種方式會導致主網站的潛在性能問題。不要緊，只要你部署一個突發的API變更，你必須同時重新部署主網站。有些原因令你不想被迫做這件事。

相反，您的網站和網絡服務應該直接與底層的業務/數據層進行通信。

接下來，不要公開EF對象本身。 Web服務界面應該比這更清潔。換句話說，它應該儘可能簡化與後端一起工作的行爲。這需要您付出相當多的努力嗎？是。但是，如果您必須稍微更改型號而不影響當前連接的客戶端，它將帶來收益。

2011-02-25 18:11:07 NotMe

報價「相反，您的網站和Web服務應該直接與底層業務/數據層進行通信。」我想他想說他使用相同的服務層（而不是數據層），我認爲他在內部不使用WCF，他只是在本地調用相同的服務方法。 – 2011-02-25 18:19:01

@Alex Burtsev：不是根據他的評論... – NotMe 2011-02-25 18:21:15

這裏不是「問題」，如果我們發現性能問題，那麼我們必須做出更好的Web服務？試圖防止開發人員將Web服務推到一邊，轉而採用客戶無法使用的更高效的內部方法。 – Brandon 2011-02-25 18:21:52

這取決於項目的複雜性以及您期望它生存多久。對於小而短的生活項目，您可以跨所有圖層共享域對象。但是，如果它的大項目，你希望它存在，做工精良，併爲未來5年更新....

在我目前的項目（大），我第一次開始在所有圖層共享實體，然後我發現我需要單獨的實體進行演示，現在（6個月過去了）我爲每個層（持久性，服務，域，演示文稿）使用單獨的類，這不是因爲我偏執狂或遵循一些規則，只是我不能讓與單一的一套跨層類的所有工作...讓你的結論..

PS有些工具可以幫助您轉換對象，如Automapper和Value Injecter。

2011-02-25 18:10:02

我只想振作起來，並創建專門針對應用程序的需求的API。關於暴露整個數據庫層的意義不大。只需公開需要暴露的內容以使應用程序正常工作，而不是其他任何內容。

2011-02-25 18:10:41

回答