静态业务层和扩展方法

Question

我刚刚发现了扩展方法，我非常喜欢它们，以至于我担心它们的良好用途...

我有一个 3 层的 Asp Net 应用程序。我的 DAL 基于实体框架，我的 UI 是 aspx 页面，我的业务逻辑曾经是带有 LINQ to 实体查询的公共类，如下所示：

public List<Site> GetAll()
{
     return db.Sites.Include(s=> s.City).ToList();
}

您需要像这样实例化和使用：

CSite objsite = new CSite();
List<Site> sites = objsite.GetAll();

然后我发现了 Iqueryable，所以这样我可以像这样“重用”我的查询：

public ObjectQuery<Site> GetAll()
{
     return db.Sites.Include(s=> s.City);
}

public IQueryable<Site> Filter(IQueryable<Site> query, string filterWord)
{
     return (from s in query
             s.Name.Contains(word)
             select s);
}

List<Site> sites = objsite.Filter(objsite.GetAll(),"filter word").ToList();

Filter() 方法只是在 GetAll() iqueryable 上应用一个 where 子句，这非常棒，直到我发现扩展方法，所以我可以像这样处理它：

public static IQueryable<Site> Filter(this IQueryable<Site> query, string word)
{
      return (from s in query
             s.Name.Contains(word)
             select s);
}

这甚至更好，因为现在我对我的查询有了智能感知，如下所示：

List<Site> sites = objsite.GetAll().Filter("filter word").ToList();

现在，这是我感到害怕的部分，因为三件事：

1. 您认为这是n层应用程序的好方法吗？好的设计模式还是只是一个懒惰的解决方案？

2. 考虑到扩展方法必须是静态类下的静态方法，我的业务层将全部是静态的，这是一个好方法吗？我应该将非扩展方法放在同一个静态类下吗？ （例如 GetAll() 或 AddNew()）

3. 作为 Asp Net 应用程序，拥有所有这些静态内容是否很好？

非常感谢大家！

Answer 1

在 IQueryable 之上使用自定义扩展方法是很常见的。我认为这是重用查询部分的好方法。使用扩展方法应谨慎。扩展方法只是静态方法的语法糖。我的朋友有一个关于他同事的好故事，他最近发现了扩展方法并开始使用如下代码：

var order = 1.GetOrder(); // Extension on integer - this is really bad example

您的示例中的问题是静态业务层。业务层必须以某种方式接收上下文，并且必须根据请求处理上下文。 在请求之间共享上下文或为整个应用程序提供单一上下文是最好的方式有严重的麻烦。因此，除非您将上下文传递给每个方法，否则您还必须为每个请求创建业务类。

但您仍然应该在 IQueryalbe 上使用扩展。您可能会发现您的业务类只是 context.Query 的包装器，在这种情况下，它是不需要的附加层。

另请注意，这一切都适用于分层架构，但如果您的 n 层意味着真正的物理分离（每一层都在单独的服务器上），那么情况就不同了，因为您需要一些东西来允许您在一层上创建 linq 查询并在另一层上执行它（在另一台服务器上，因此查询和结果必须通过网络传输） - WCF 数据服务就是这样的工具。