c# - 此存储库模式对于 LINQ-to-SQL 有效吗？

Question

我目前正在阅读《Pro Asp.Net MVC Framework》一书。在书中，作者建议使用类似于以下的存储库模式。

[Table(Name = "Products")]
public class Product
{
    [Column(IsPrimaryKey = true, 
            IsDbGenerated = true, 
            AutoSync = AutoSync.OnInsert)]
    public int ProductId { get; set; }
    [Column] public string Name { get; set; }
    [Column] public string Description { get; set; }
    [Column] public decimal Price { get; set; }
    [Column] public string Category { get; set; }
}

public interface IProductsRepository
{
    IQueryable<Product> Products { get; }
}

public class SqlProductsRepository : IProductsRepository
{
    private Table<Product> productsTable;

    public SqlProductsRepository(string connectionString)
    {
        productsTable = new DataContext(connectionString).GetTable<Product>();
    }

    public IQueryable<Product> Products
    {
        get { return productsTable; }
    }
}

然后通过以下方式访问数据:

public ViewResult List(string category)
{
    var productsInCategory =  (category == null) ? productsRepository.Products : productsRepository.Products.Where(p => p.Category == category);

    return View(productsInCategory);
}

这是访问数据的有效方法吗？是否会从数据库中检索整个表并在内存中进行过滤，或者链接的Where() 方法是否会导致一些 LINQ 魔法基于 lambda 创建优化的查询？

最后，当通过 LINQ-to-SQL 连接时，C# 中存储库模式的其他哪些实现可能会提供更好的性能？

Answer 1

我能理解Johannes'希望更严格地控​​制 SQL 的执行，并且通过实现我有时称之为“惰性 anchor ”的内容，我已经能够在我的应用程序中做到这一点。

我使用自定义的组合LazyList<T>和LazyItem<T>封装延迟初始化的类:

• LazyList<T>包裹 IQueryable IList的功能集合，但最大化 LinqToSql 的一些延迟执行函数，并且
• LazyItem<T>将使用 LinqToSql IQueryable 包装单个项目的延迟调用或通用 Func<T>延迟执行其他代码的方法。

这是一个例子 - 我有这个模型对象 Announcement其中可能附有图像或 pdf 文档:

public class Announcement : //..
{
    public int ID { get; set; }
    public string Title { get; set; }
    public AnnouncementCategory Category { get; set; }
    public string Body { get; set; }
    public LazyItem<Image> Image { get; set; }
    public LazyItem<PdfDoc> PdfDoc { get; set; }
}

Image和PdfDoc类继承类型File包含 byte[]包含二进制数据。这个二进制数据很重，我可能并不总是需要每次我想要 Announcement 时从数据库返回它。 。所以我想保持我的对象图“锚定”而不是“填充”(如果你愿意的话)。

所以如果我做这样的事情:

Console.WriteLine(anAnnouncement.Title);

..我可以知道我只从数据库加载了立即的数据 Announcement目的。但如果在下面一行我需要这样做:

Console.WriteLine(anAnnouncement.Image.Inner.Width);

..我可以确定LazyItem<T>知道如何获取其余数据。

另一个巨大的好处是这些“惰性”类可以隐藏底层存储库的特定实现，因此我不一定必须使用 LinqToSql。我(使用 LinqToSql)在我正在从中剪切示例的应用程序的情况下，但是很容易插入另一个数据源(甚至可能不使用存储库模式的完全不同的数据层)。

LINQ 但不是 LinqToSql

您会发现，有时您想要执行一些奇特的 LINQ 查询，当执行流向 LinqToSql 提供程序时，这些查询会发生错误。这是因为 LinqToSql 的工作原理是将有效的 LINQ 查询逻辑转换为 T-SQL 代码，但有时这并不总是可行。

例如，我有一个函数，我想要 IQueryable结果来自:

    private IQueryable<Event> GetLatestSortedEvents()
    {
        // TODO: WARNING: HEAVY SQL QUERY! fix
        return this.GetSortedEvents().ToList()
            .Where(ModelExtensions.Event.IsUpcomingEvent())
            .AsQueryable();
    }

为什么该代码不转换为 SQL 并不重要，但请相信我 IsUpcomingEvent() 中的条件谓词涉及多个DateTime对于 LinqToSql 来说，比较太复杂，无法转换为 T-SQL。

通过使用 .ToList()然后条件( .Where(.. )然后 .AsQueryable()我实际上是在告诉 LinqToSql 我需要所有 .GetSortedEvents()即使我要过滤它们。在这个实例中，我的过滤表达式无法正确呈现为 SQL，因此我需要在内存中对其进行过滤。就延迟执行和延迟加载而言，这就是我所说的 LinqToSql 性能的限制 - 但我只有其中的一小部分 WARNING: HEAVY SQL QUERY!我的应用程序中存在 block ，我认为进一步的智能重构可以完全消除它们。

最后，如果您愿意，LinqToSql 可以在大型应用程序中成为一个优秀的数据访问提供程序。我发现为了获得我想要的结果并抽象和隔离某些东西，我需要到处添加代码。当我想要更多地控制 LinqToSql 的实际 SQL 性能时，我添加了智能以获得所需的结果。因此，恕我直言，如果您了解 LinqToSql 的工作原理，那么 LinqToSql 对于需要数据库查询优化的重型应用程序来说是完全可以的。我的设计最初是基于Rob的Storefront tutorial因此，如果您需要对我上面的咆哮进行更多解释，您可能会发现它很有用。

如果你想使用上面那些惰性类，你可以得到它们 here和 here .