2010-06-16 30 views
0

我正在「升級」一個MVC應用程序。以前,DAL是Model的一部分,作爲一系列使用標準LINQ to SQL查詢的存儲庫(基於實體名稱)。現在,它是一個單獨的項目,並使用PLINQO生成。使用PLINQO生成的數據時使用存儲庫模式?

由於PLINQO基於實體的屬性查詢擴展,我開始直接在我的控制器使用它們...並消除了庫中的所有在一起。

它工作正常,這是更多的問題來借鑑你的經驗,我應該繼續這個道路還是應該重建庫(使用PLINQO作爲庫文件中的DAL)?產生只是用PLINQO的

一個好處數據上下文是,當我需要的數據庫訪問,我只是做一個參考的數據上下文。在存儲庫模式下,我需要在需要數據訪問時引用每個存儲庫,有時需要在單個控制器上引用多個存儲庫。

最大的好處我就看見倉庫,被恰當地命名的查詢方法(即FindAllProductsByCategoryId(INT ID),等...)。使用PLINQO代碼,它是_db.Product.ByCatId(int id) - 這也不算太差。

我喜歡這兩個,但它在哪裏得到「har」是當查詢使用謂詞。我可以將它捲入存儲庫查詢方法。但是在PLINQO代碼上,它會像_db.Product.Where(x => x.CatId == 1 & & x.OrderId == 1);我不太確定我喜歡在控制器中使用這樣的代碼。

你對此有何看法?

回答

2

- 查詢擴展 -

PLINQO的查詢擴展被設計成可鏈接。這應該有助於防止事情變得太「哈利」。 )

// LAMBDA
_db.Product.Where(X => x.CatId == 1 & & x.OrderId == 1);
//查詢擴展
_db.Product.ByCatId(1).ByOrderId(1);

//甚至更復雜的λ
_db.Product.Where(X =>(x.CatId == 1 || x.CatId == 3)& & x.OrderId = 1!);
//查詢擴展
_db.Product.ByCatId(1,3).ByOrderId(ComparisonOperator.NotEqual,1);

此外,對於真正複雜的查詢,我們建議增加自定義擴展方法可編輯(被動產生的)查詢擴展名的文件。這使您可以將更先進的邏輯封裝到一個地方,並使代碼更清晰和高級邏輯更加可重用。

http://docs.codesmithtools.com/display/PLINQO/Query+Extensions

- 模式 - 以

至於模式,我們一般建議您新興起來的一個DataContext在using語句要訪問數據庫每次。 LINQ to SQL(以及PLINQO)正在使用工作單元模式,並且旨在在小型受控範圍內正常工作。

+0

另外看看這個PLINQO視頻http://www.youtube.com/watch?v=4CSXNWvFSwI – 2010-06-16 16:58:11

+0

這是一個很好的觀點。我一直在構建自定義查詢擴展,主要用於連接場景......但絕對可以構建更多。 關於使用聲明...這是我正在做的。我所有的控制器都來自一個自定義的基礎控制器。由於我的所有控制器都需要訪問數據庫,因此我只需在基礎控制器中新建一個DataContext。 使用說明是否有性能優勢?這意味着我需要在每個控制器的幾乎每個動作中都使用一個使用語句。 – Chaddeus 2010-06-16 22:52:09

+0

這是一個非常深入的答案:http://stephenwalther.com/blog/archive/2008/08/20/asp-net-mvc-tip-34-dispose-of-your-datacontext-or-don -t.aspx :) – tdupont 2010-06-22 17:33:48

相關問題