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作为索引器的观点可能是指它存储在数据库中。使用整数作为密钥可以提供更好的性能，并且比使用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();
}

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

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

2 个答案: