0

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

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

它工作正常，这更像是一个借鉴您的经验的问题，我应该继续沿着这条路走还是应该重建存储库（使用 PLINQO 作为存储库文件中的 DAL）？

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

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

我两者都喜欢，但是当查询使用谓词时，它会变得“鹞”。我可以将其汇总到存储库查询方法中。但是在 PLINQO 代码上，它类似于 _db.Product.Where(x => x.CatId == 1 && x.OrderId == 1); 我不太确定我是否喜欢在我的控制器中使用这样的代码。

你对此有何看法？

4

1 回答 1

2

-- 查询扩展 --

PLINQO 的查询扩展被设计为可链接的。这应该有助于防止事情变得过于“哈利”。;)

// Lambda
_db.Product.Where(x => x.CatId == 1 && x.OrderId == 1);
// 查询扩展
_db.Product.ByCatId(1).ByOrderId(1);

// 更复杂的 Lambda
_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

- 图案 -

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

于 2010-06-16T16:54:30.690 回答