使用WCF數據訪問和業務邏輯層

Question

我們正在開發一個Web應用程序，稍後還將移植到移動設備上。所以我正在考慮在WCF層中封裝數據訪問和業務邏輯。這將使以後同步和管理更容易。

數據訪問層將由ORM（Codesmith - PLINQO）之上的存儲庫層組成。 該應用程序是多租戶（SaaS）並使用共享數據庫方法。

WCF和Web應用程序將駐留在同一服務器上，WCF綁定將是NamedPipes。

上述方法是否正確或者在使用WCF層時可能會有一些性能問題？任何建議或可讀的材料更好地構建應用程序也受到歡迎。

Answer 1

這取決於您的其他要求。命名管道通信總是有性能問題。您可以進行一些測試以直接多次調用操作，並通過命名管道調用操作來獲取一些數字進行比較。可以選擇命名管道來代替另一個進程託管服務 - null channel或local channel，但即使這些解決方案仍會比直接調用更慢。

您正在規劃未來的架構，因此您現在應該定義未來的意義。移動設備將如何消耗您的服務？它會成爲SOAP還是REST？這些是兩種不同的方法，您可以發現爲您的Web應用程序（SOAP）準備的服務對於移動設備（您可以使用REST，因爲它受到更好的支持和更受歡迎）而言並不是非常有用。

如果你不知道未來意味着什麼做任何準備是沒有意義的，因爲你很可能會準備一些不會發生的事情=你目前的努力將被浪費，你將不得不稍後改變你的應用程序無論如何。

對您的應用程序（=內部服務）和移動設備（=外部服務）使用相同的服務可能會有不同的安全要求。例如，您的Web應用程序可以處理授權，但對於移動設備，授權將必須在服務上執行。授權是全球性的服務，所以對於您的Web應用程序，您將執行兩次授權。

在我看來，你應該從業務邏輯開始，作爲一個庫，它將被你的web應用程序直接使用。一旦您需要爲移動設備添加服務，只需在業務邏輯周圍創建服務包裝。如果要在不同服務器上分割前端和後端，或者如果要分別縮放業務邏輯和前端，但在同一臺服務器上運行時只會引入性能下降，爲您的Web應用程序添加WCF層是有意義的。可能不會使您的移動設備開發更容易。即使在需要單獨部署業務邏輯的情況下，如果要直接向移動設備公開業務服務，也應仔細考慮。公開另一層調用內部業務服務的公共服務並不少見 - 通常用於安全性較強的項目，其中業務服務必須位於不同的網絡邊界。