使用linq-to-sql的2層（客戶端 - 服務器）桌面應用程序的良好體系結構

我們現在的架構-UI，BusinessLayer，DAL（生成的linq-to-sql）。在DAL層，我們添加了驗證邏輯對於部分類中的實體。我們直接在businesslayer中使用由linq-to-sql生成的實體（這是一堆類 - 類\ form）。同樣，在這些bll類中，我們創建了linq-to-sql查詢。使用linq-to-sql的2層（客戶端 - 服務器）桌面應用程序的良好體系結構

我覺得我們可以根據MVP模式對應用程序進行更好的分層，並且有使用linq-to-sql提供數據的服務類。您怎麼看？我應該考慮存儲庫模式嗎？這會是一個矯枉過正的問題嗎？

來源

2010-02-15 junky_user

這是一個好主意！

您的choise取決於你的應用程序，但這些都是很多問題：

1）對象數據庫模型和對象模型的應用程序之間的轉換可以變得更加困難。在這種情況下，不可能在應用程序的模型上實現過濾器，以便將生成的查詢傳送到SQL中。

2）通常，作爲採樣必須獲得（從一個表

3）JOIN）多個表，並不僅數據的連接的結果的結果並不是所有的SQL的操作和功能有其等效在LINQ

實體框架呢？請不要觸摸實體框架。這是沉重而緩慢的事情！ :)

我更喜歡通過存儲過程的經典數據訪問和數據訪問從MS企業庫。我可以使用SQL的強大功能和我自己的業務實體的靈活性。當然 - 表現！獎牌的反面是更多的工作。我使用了一些工具來自動生成數據訪問對象，然後根據需要修復它們。

好運！

來源

2010-02-15 23:10:05 garik

所有好東西都需要思考，但是當你開始沿着這條道路前進時，我相信你會有更多的問題而不是回答很多時間！

當您提到桌面和Linq-To-SQL時，我會假定您使用的是Windows窗體，這會給您在實現諸如MVP模式之類的東西時帶來一些挑戰。

雖然有針對WinForms（MVC＃）的預先定製的MVP框架，但如果您不開發大型應用程序，那麼您可能需要輕鬆地開始並使用自己的代碼實現一些概念。

傑里米·米勒的出色Build Your Own CAB系列文章是一個很好的資源在這裏，你可以採取一些前幾個想法離開那裏，並得到您的形式（演講）和業務邏輯（主持人和服務類之間的一些涉及分離）。我們喜歡在工作中主要使用監督控制器設計，但是它的價值在於看待其他模式，比如被動視圖和Model-View-ViewModel（它被烘焙成WPF工作方式，非常值得了解），看看你覺得最舒服。

至於你對服務類或存儲庫的問題，我認爲你想要的主要兩個邏輯級別是Presenter或ViewModel實體，然後是服務實體，它下面可以包含像Linq-To- SQL查詢。所以，你可能已經有很多爲您服務層有邏輯的，但它更重構它變成一個一致的形式的情況。

來源

2010-02-16 03:10:30 Soundwave

是的，我正在尋找一致性。尤其是，要獲得linq-to-sql代碼到服務類（linq代碼遍佈整個） – 2010-02-16 04:07:12

我已經重構了MVP風格的幾個表單。 – 2010-02-16 04:08:40

這聽起來像你在正確的軌道上。如果你有一個WCF服務層您可以在過程中或通過HTTP，這意味着你可以支持客戶端服務器類型的應用程序，而不是從前端擊中DB運行它，但它確實取決於你的應用。

來源

2010-02-16 15:05:48 Burt

MVP可能很難理解開發者，但你可以給它一個去。

來源

2010-02-16 15:50:40 ASharp

你爲什麼說「很難理解」？ – 2010-02-17 10:25:12

使用linq-to-sql的2層（客戶端 - 服務器）桌面應用程序的良好體系結構

回答

相關問題