使用索引器从数据存储中检索 Linq to SQL 对象

Question

class UserDatastore : IUserDatastore
{
    ...

    public IUser this[Guid userId]
    {
        get
        {
            User user = (from u in _dataContext.Users
                             where u.Id == userId
                             select u).FirstOrDefault();

            return user;
        }
    }

    ...
}

我们团队中的一位开发人员认为，上述情况下的索引器并不合适，应该首选 GetUser(Guid id) 方法。

论据是：

1）我们没有索引到内存中的集合，索引器基本上执行隐藏的 SQL 查询 2) 在索引器中使用 Guid 是不好的（FxCop 也标记了这一点） 3) 从索引器返回 null 不是正常行为 4) API 用户通常不会期望任何这种行为，

我在一定程度上同意（大部分）这些观点。

但我也倾向于认为 Linq 的特征之一是抽象数据库访问，使您看起来只是在处理一堆集合，即使惰性求值范例意味着这些集合不会被求值直到您对它们运行查询。对我来说，以与这里的具体内存集合相同的方式访问数据存储似乎并不矛盾。

另请记住，这是一个继承的代码库，广泛且一致地使用此模式，是否值得重构？我承认从一开始就使用 Get 方法可能会更好，但我还不确信使用索引器是完全错误的。

我很想听听大家的意见，谢谢。

Answer 1

我倾向于同意您的团队开发人员建议的几乎所有内容，除了 Guid 部分。如果这里有任何问题，考虑到性能，它一定是在数据库级别，而不是在您的代码中。

我个人认为属性和索引器不应该隐藏长时间运行的操作，尽管用户可以通过LINQ-to-SQL进行缓存。这就是为什么我也更喜欢一种方法。

我也同意从索引器返回 null 是不好的。相反，抛出异常。

Answer 2

我认为他关于使用 GUID 作为索引器的观点可能是指它存储在数据库中。使用整数作为键将提供更好的性能，并且比使用 GUID 占用更少的存储空间。

返回 null 的情况非常罕见，因为通常使用索引器时，如果索引（键）不在集合中，您将抛出异常。

就我个人而言，我并没有真正看到这里的问题，它几乎相当于有一个 GetUser 方法。我的意思是，如果您想稍微整理一下，您实际上可以引入一个名为 GetUser 的私有方法，索引器可以调用该方法，例如

public IUser this[Guid userId]
{
    get { return GetUser(userId); }
}

private IUser GetUser(Guid userId)
{
    return (from u in _dataContext.Users 
            where u.Id == userId 
            select u).FirstOrDefault();
}

从设计的角度来看，我个人不会使用索引器，我会使用 GetUser 方法。