將WPF桌面應用程序轉移到客戶端服務器技術的良好體系結構

Question

我有一個可用於單臺PC的WPF應用程序。我已經使用SQL服務器數據庫，實體框架與數據庫 和應用程序中的RDLC報告進行通信。現在需求已經到了，使得這個應用程序可以在多個用戶（通常在25個左右）訪問應用程序的本地公司網絡上工作，這取決於角色和權限的設置。我做了這方面的一些[R & d，主要使用的架構這裏提到http://www.codeproject.com/Articles/434282/A-N-Tier-Architecture-Sample-with-ASP-NET-MVC-WCF，而這樣做之後，我已經提出申請的一紙設計/架構，將看起來像這樣

的WCF服務運行公司網絡內的高端服務器

1. GPC.Service本身 - 定義協議來連接到服務 和所有其他必要的信息
2. GPC.Algorithm - 將成爲主要的商業邏輯層將 包含的邏輯和將接口連接到客戶端調用 數據庫層方法
3. GPC.Persistance - 將有一個像 取實際的數據庫交互方法/存儲/更新/刪除數據庫
4. GPC.Data記錄 - 這將包含EDMX架構實體 Framwework
5. GPC.Entites - 這將包含數據庫架構的實體 和addional部分類

個

**

客戶：

客戶將基於MVVM模式現在WPF應用程序（可能在將來，我們將需要移動Web應用程序，但不是必需的現在）。應用程序的主要組件是：

1. 從excel導入：目前所有數據都在Excel文件中。需要將所有數據導入到系統中。
2. 編輯/更新/刪除：一旦數據被導入，讓界面對用戶 編輯/更新/刪除記錄
3. 生成reprots（使用RDLC本）
4. 用戶/角色管理等

共享： 這是包含像代碼目前存在的miscelenious一個類庫來讀取excel文件，處理錯誤，類別，這將是結合到UI等

數據庫上下文：將在每個方法的Persistance圖層中的using語句中創建，以確保沒有陳舊的信息。

這個架構是否遵循n層架構，它是否靈活？這方面需要做什麼改進，請指導我如何改進任何問題。在繼續並改變我現有的應用程序之前，我想確保這是一個很好的架構。

Answer 1

這是非常有意義的。 （嘗試構建它的TDD風格）

爲了讓您的生活更輕鬆一些，客戶端版本管理員考慮使用ClickOnce安裝程序在您的用戶計算機上執行最新版本的安裝（一旦您將其移動爲一個Web應用程序）。

Answer 2

看起來好像你在正確的道路上，但是你可能在某些領域工程過度。

我認爲在很大程度上EntityFramework爲您處理實體，數據和持久層。除非您希望最終將EntityFramework替換爲其他一些ORM系統，否則自己實現它們可能會過度。

您正在使用GPC.Services庫瀏覽SOA（面向服務的體系結構）。在這裏，您需要了解如何將服務層分解爲一個或多個服務於客戶端應用程序的atmoic服務。有很多方法可以解決這個問題，並且主要取決於您打算如何使用服務層。看看RESTful服務，它很好地分解了服務層，並將引導您構建整潔的atmoic服務。查看這個Asp.net Web API。

我想你在你的GPC.Alogrithms庫中尋找的是一個真正的領域模型。域模型封裝了您的所有業務邏輯，並允許您通過公開的函數對對象執行狀態更改。考慮到這一點的系統的層將如下所示：

持久性（EF） - >域模型 - >服務層 - > DTO（數據傳輸對象） - >客戶端

的DTO對象上述將會是一組POCO（Plain Old C＃對象），它們負責向客戶端發送數據和從客戶端發送數據。由於反向引用和其他封裝問題，序列化和淡化您的域對象將變得有問題，因此您需要這樣做。把DTO放在適當的位置將強化一個上下文邊界，這是SOA的原則之一 - 「Boundarys是明確的」，參見this for more info on soa

對於客戶端來說，似乎你正在跟蹤。您可能想要做的是重構當前客戶端應用程序，以便將所有數據查詢合併到一個圖層中。所以，當時間到了，你會用服務實現來替換這個層。