在控制器中进行 linq 查询是一种好习惯吗？

Question

我对 MVC 模式不是很熟悉。你能告诉我以下三个控制器动作中哪一个更好吗？谢谢:)

(1) 有查询：

public ActionResult List()
{
   var query = repository.Query().Where(it => it.IsHandled).OrderBy(it => it.Id);
   // ...
}

(2) 有查询服务：

public ActionResult List() 
{
    var items = service.GetHandledItemsOrderById();
    // ...
}

(3) 行动有序：

public ActionResult List()
{
    var items = service.GetHandledItems().OrderBy(it => it.Id);
    // ...
}

如果我们选择（1），那么控制器中的业务逻辑太多了？

如果我们选择（2），可能会有很多类似GetXXXByYYY()的服务方法。

如果我们选择（3），为什么我们封装Where(it => it.IsHandled)而不是
OrderBy(it => it.Id。

有什么想法吗？

Answer 1

我确信意见可能会有所不同，但我已经学会了尽量在服务中保留尽可能多的业务逻辑。 3是我的选择。使用 1，您已经发现了问题。使用 2，您将在服务中引入显示优先级。使用 3，您可以在必要时处理显示首选项。如果您要为业务层引入另一个接口，您可能需要通过选择 2 进行不必要的代码迭代。

Answer 2

视情况而定。 :)

我的看法：

我喜欢保持服务松散，以尽量减少重复代码。我也是管道和过滤器的粉丝。

这就是我会做的（并且会做的）。

服务

public ICollection<Item> GetHandledItems<TKey>(OrderingOptions<Item, TKey> orderingOptions) 
{
   return repository
      .Query()
      .WhereHandled()
      .WithOrdering(orderingOptions)
      .ToList();     
}

ItemFilters.cs

public static IQueryable<Item> WhereHandled(this IQueryable<Item> source)
{
   return source.Where(it => it.IsHandled);
}

public static IOrderedQueryable<T> WithOrdering<T, TKey>(
   this IQueryable<T> source,
   OrderingOptions<T, TKey> orderingOptions)
{
   return orderingOptions.SortDescending 
      ? source.OrderByDescending(orderingOptions.OrderingKey) :                                                    
        source.OrderBy(orderingOptions.OrderingKey);
}

OrderingOptions.cs

 public class OrderingOptions<T,TKey>
 {
    public OrderingOptions(Expression<Func<T,TKey>> orderingKey, bool sortDescending = false)
    {
       OrderingKey = orderingKey;
       SortDescending = sortDescending;
    }

    public Expression<Func<T,TKey>> OrderingKey { get; private set; }
    public bool SortDescending { get; private set; }
 }

这样，你可以在Controller中指定排序：

var items = service.GetHandledItems(new OrderingOptions(it => it.Id));

上述与选项3的区别：

• 在返回到控制器之前实现了上述序列。选项 3 没有，这很危险（您最终可能会将查询返回到 View 并破坏 MVC 模式）。
• 通用“订购”POCO，可在任何地方使用，让您的查询保持 D-R-Y。
• 服务变得愚蠢，并且只是存储库和控制器之间的缓解器（这就是它应该做的，IMO）。将逻辑（例如过滤器）抽象到一个地方。