在控制器中使用 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

这要看情况。 :)

我的观点：

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

这就是我要做的（并且确实要做的）。

Service

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; }
 }

这样，您可以在控制器中指定排序：

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

上面和选项3之间的差异：

• 上面具体化返回控制器之前的顺序。选项 3 不会，这很危险（您可能最终将查询返回到 View 并破坏 MVC 模式）。
• 通用“订购”POCO，可以在任何地方使用并保持您的查询干燥。
• 服务变得哑，并且只是存储库和控制器之间的缓解器（这就是它应该做的，IMO）。逻辑（例如过滤器）抽象到一处。