基於REST的MVC站點和/或WCF

我知道其實有很多類似於這個問題的問題，但是我找不到完全回答我的問題的問題。基於REST的MVC站點和/或WCF

我建立一個Web應用程序，將

明顯數據顯示給用戶:)
有身份驗證的用戶一個公共API使用
後來被移植到移動設備

所以，我被困在設計上。我將爲網站使用asp.net MVC，但是我不確定如何在此之後構建我的架構。

我應該：

使網站的RESTful並作爲API
- ，則GET返回完整視圖，而不僅僅是數據，這對我來說似乎是它殺死公共API的想法也應該真的在我的控制器中執行業務邏輯嗎？爲了能夠擴展，在另一臺服務器上擁有一個單獨的業務邏輯層不是更好，還是隻考慮將我的MVC站點推送到另一臺服務器，它將解決同樣的問題？我想創建一個SOLID設計，所以它也似乎更抽象的這一個單獨的服務（我可能只是調用另一個類，但後來我回到可擴展性的問題......）
使網站不支持REST和創建，該網站將使用
使雙方的網站和WCF服務，是寧靜的一個RESTful的WCF服務，然而，這似乎是多餘的

我是相當新的休息，所以這個問題可能是我的一個誤解。希望我解釋得很好，但如果沒有，請讓我知道你是否需要任何澄清。

來源

2012-02-01 Justin Pihony

我會做一個單獨的業務邏輯層和一個（平靜的）WCF層。這將您的BLL從您的客戶端分離出來。你甚至可以讓不同的客戶端使用相同的API（並不是說你應該，或者會，但是它給了你靈活性）。理想情況下，您的服務層不應返回您的域實體，而應返回數據傳輸對象（您可以使用Automapper進行映射），但它取決於項目的範圍和規格。

將它放在另一臺服務器上使其成爲不同的層，層<>層。

來源

2012-02-01 18:01:30 diggingforfire

是的，我計劃使用DTO和AutoMapper。所以，你在說，我可能不應該擔心REST網站，而是讓它使用RESTful服務？（本質上是選項2） – 2012-02-01 18:19:50

就是這樣，儘管服務層！= BLL。您的服務層應負責DTO <->實體映射。您的業務邏輯適用於實體，不需要服務或數據傳輸知識。 – diggingforfire 2012-02-01 18:25:47

是的，我完全同意。事實上，這是我打算繼續使用我的網站作爲RESTful服務本身之前計劃的架構。 – 2012-02-01 18:30:58

平原和簡單.... 從複雜的角度來看，將網站和您的API分開是最簡單的方法。這也有點清潔劑 IMO也是。

但是，如果您決定走這條路線，可以採取以下一些技巧來使處理起來更容易一些。（我目前正在做一個我正在開展的個人項目）

保持你的控制器邏輯非常裸露。根據你想使它成爲固體的事實，你可能已經在做這件事了。
將從實際模型返回到視圖的模型分開。我喜歡創建特定於視圖的模型，並有一種將模型轉換爲此視圖特定模型的方法。
確保您的版本全部。您可能會希望允許並支持一段時間內傳入的舊API請求，特別是在手機上。
實際上使用REST是最充分的，而不僅僅是HTTP的另一個名稱。大多數實現都錯過了這樣一個事實：在任何類型的響應中，狀態都應該與它一起傳輸（缺少ST）。允許在頁面和API響應中自行發現操作。例如，如果您允許在資源中分頁，請始終在api或網頁中指定。有an entire wikipedia page on this。這非常有助於解耦，允許您有時使用最新版本自動更新客戶端。

現在你控制器動作可能會看起來像這樣的僞代碼

MyAction(param) { 
    // Do something with param 
    model = foo.baz(param) 

    // return result 
    if(isAPIRequest) { 
     return WhateverResult(model) 
    } 
    return View(model.AsViewSpecificModel()) 
}

有一件事我一直在玩弄自己正在我自己的類型的ActionResult，處理返回邏輯，以便在整個項目中不會重複。

來源

2012-02-01 18:26:04 scottheckel

謝謝，這似乎與@ diggingforfire的迴應一樣，除了你的第4點。你是說我應該更多地選擇第三個選項（MVC和WCF都是REST ）？如果是這樣，你能否詳細說明爲什麼這不是多餘的？ – 2012-02-01 18:36:50

我指的是API應該由「超文本」驅動的事實。我會清理它。 – scottheckel 2012-02-01 20:35:44

謝謝，那已經是我對REST的理解了，所以我應該沒問題:) – 2012-02-01 21:05:38

我會爲您的網站使用REST服務，因爲它不會增加任何重要的開銷（假設它們在同一臺服務器上）並且會大大簡化您的代碼庫。而不是有2個API：一個私有（作爲DLL參考）和一個公共，你可以「吃你自己的狗食」。唯一需要謹慎行事的方法是確保不要彎曲公共API來滿足自己的需求，而是在需要時擁有單獨的私有API。

您可以使用RestSharp或EasyHttp進行MVC站點內的REST調用。

ServiceStack可能會使API任務更容易，您可以使用現有的域對象，並且只需編寫一組服務即可獲取/更新/刪除/創建對象，而無需爲MVC中的所有內容編寫2個操作。

來源

2012-02-01 18:44:47

所以，你也建議選項2呢？這似乎是普遍的共識。 – 2012-02-01 18:54:19

@Justin絕對不會去我的經驗WCF路線。 – 2012-02-01 20:21:40

爲什麼不呢？它似乎具有很好的REST風格。如果不是WCF，你會建議什麼？我願意使用其他語言，但寧願將東西放在同一個技術堆棧中。 – 2012-02-01 20:32:14

基於REST的MVC站點和/或WCF

回答

相關問題