2 
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;
        }
    }

    ...
}

私たちのチームの開発者の 1 人は、上記の状況でのインデクサーは適切ではなく、GetUser(Guid id)メソッドを優先すべきであると主張しています。

引数は次のとおりです。

1) インメモリ コレクションにインデックスを作成していません。インデクサーは基本的に非表示の SQL クエリを実行しています 2) インデクサーで Guid を使用するのは良くありません (FxCop はこれにもフラグを立てました) 3)nullインデクサーから戻るのは通常の動作ではありません4) API ユーザーは通常、このような動作を予期しません。

私はこれらの点（のほとんど）にある程度同意します。

しかし、Linq の特徴の 1 つは、データベース アクセスを抽象化して、単に多数のコレクションを操作しているように見せかけることだとも主張しがちです。遅延評価パラダイムは、これらのコレクションが評価されないことを意味しますがそれらに対してクエリを実行するまで。ここで具体的なメモリ内コレクションであるかのようにデータストアにアクセスすることは、私には矛盾しているようには見えません。

また、これはこのパターンを広範かつ一貫して使用する継承されたコードベースであることを念頭に置いて、リファクタリングする価値はありますか? 最初から Get メソッドを使用したほうがよかったかもしれないことは認めますが、インデクサーを使用することが完全に間違っているとはまだ確信していません。

私はすべての意見を聞くことに興味があります、ありがとう。

4

2 に答える 2

0

一部を除いて、チーム開発者が提案したほとんどすべてに同意する傾向がありますGuid。ここで問題がある場合は、コードではなく、パフォーマンスを考慮してデータベースレベルである必要があります。

個人的には、プロパティとインデクサーは、LINQ-to-SQLによってキャッシュされる可能性はありますが、長時間実行される操作を隠すべきではないと思います。Usersだから私も方法を好むのです。

また、インデクサーからnullを返すのは悪いことでもあります。代わりに例外をスローします。

于 2010-04-15T11:03:57.580 に答える
0

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メソッドを使用していたでしょう。

于 2010-04-15T10:56:06.437 に答える