应用错误收集

我正在“升级”MVC应用。以前，DAL是Model的一部分，作为一系列使用标准LINQ to SQL查询的存储库（基于实体名称）。现在，它是一个单独的项目，使用PLINQO生成。

由于PLINQO根据实体的属性生成查询扩展，我开始直接在我的控制器中使用它们......并且一起消除了存储库。

它工作得很好，这是一个可以借鉴你的经验的问题，我应该继续沿着这条路走，还是应该重建存储库（使用PLINQO作为存储库文件中的DAL）？

使用PLINQO生成的数据上下文的一个好处是，当我需要数据库访问时，我只需要对数据上下文进行一次引用。在存储库模式下，我需要在需要数据访问时引用每个存储库，有时需要在单个控制器上引用多个存储库。

我在存储库中看到的最大好处是适当命名的查询方法（即FindAllProductsByCategoryId（int id）等...）。使用PLINQO代码，它是_db.Product.ByCatId（int id） - 这也不错。

我喜欢这两个，但它获得“harrier”的地方是查询使用谓词时。我可以将其推广到存储库查询方法中。但是在PLINQO代码上，它会像_db.Product.Where（x =＆gt; x.CatId == 1＆amp;＆amp; x.OrderId == 1）;我不太确定我喜欢在我的控制器中使用这样的代码。

你对此有什么看法？

- QUERY EXTENSIONS -

PLINQO的查询扩展程序旨在实现可链接。这应该有助于防止事情变得太“har”。 ;）

// Lambda
_db.Product.Where（x =＆gt; x.CatId == 1＆amp;＆amp; x.OrderId == 1）;

//查询扩展名
_db.Product.ByCatId（1）.ByOrderId（1）;

//更复杂的Lambda
_db.Product.Where（x =＆gt;（x.CatId == 1 || x.CatId == 3）＆amp;＆amp; x.OrderId！= 1）;

//查询扩展名
_db.Product.ByCatId（1,3）.ByOrderId（ComparisonOperator.NotEqual，1）;

此外，对于非常复杂的查询，我们建议将自定义扩展方法添加到可编辑（被动生成的）查询扩展文件中。这使您可以将更高级的逻辑封装到一个位置，并使代码更清晰，高级逻辑更可重用。

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

- PATTERN -

对于模式，我们通常建议您每次要访问数据库时在using语句中新建一个DataContext。 LINQ to SQL（以及PLINQO）正在使用工作单元模式，并且设计用于在小型受控范围内很好地工作。

使用PLINQO生成的数据时使用存储库模式？

1 个答案: