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 方法可能会更好,但我还不确定使用索引器是完全错误的。
我很想听听所有意见,谢谢。
最佳答案
除了 Guid
部分外,我倾向于同意您的团队开发人员提出的几乎所有建议。如果这里有任何问题,考虑到性能,它一定是在数据库级别,而不是在您的代码中。
我个人认为 Properties 和 Indexers 不应该隐藏 long 运行的操作,尽管 Users
可以被 LINQ-to-SQL 缓存。这就是为什么我也更喜欢一种方法。
我也同意从索引器返回 null 是不好的。而是抛出异常。
关于c# - 使用索引器从数据存储中检索 Linq to SQL 对象,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2644554/