2010-06-16 72 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

相关问题