2

私は自分のプロジェクトにリポジトリ/サービスの設計パターンを採用しました。それを構築しているときに、私は自分自身に考えました。

リポジトリのすべてのアイテムを取得 (キャッシュに保持) してから、呼び出しごとにデータベース接続を使用するのではなく、LINQ を使用してフィルター処理する方がよいでしょうか。

たとえば、私はこれを持っています：

public Asset Get(int id)
{
    return GetAll().Where(a => a.Id == id).FirstOrDefault();
}

public IList<Asset> GetAll()
{
    return AssetData.Get(userId, companyId);
}

それ以外の：

public Asset Get(int id)
{
    return AssetData.Get(id, userId, companyId);
}

public IList<Asset> GetAll()
{
    return AssetData.Get(userId, companyId);
}

システムを高速化し、データベース接続/クエリが少なくなるため、最初の方法が最適だと思います。

では、このシナリオのベスト プラクティスはどれか説明してもらえますか?

4

2 に答える 2

4

これは時期尚早の最適化です。アプリケーションを使い始めるまで、ボトルネックがどこにあるのかわかりません。パフォーマンス ヒットが発生し始めるまで待ってから、パフォーマンスを向上させるために何ができるかを検討してください。また、多くのサービスが日常的に使用している実証済みのテクノロジを推測することもできます。データベースは、適切に処理すれば、かなり堅牢で高いパフォーマンスを発揮します。

リポジトリをインターフェイスの背後に置くことで、正しいことを行いました。これにより、使用するコードを変更せずに実装を柔軟に変更できます。キャッシングが組み込まれているNHibernateのような ERM ソリューションの使用を検討してください。

于 2013-08-05T16:22:51.033 に答える
2

@Brian がコメントしたように、ここでの大きな問題は、あなたとあなたの特定のシナリオに最適なものは何かということです。私は（個人的には）リクエスト間で古くなる可能性のあるアプリケーションデータをキャッシュすることに注意します。つまり、ユーザーがあなたのケースでアセットレコードを更新しましたが、キャッシュされているため、ユーザーは更新まで更新を見ることができませんキャッシュの有効期限が切れているか、更新されています (混乱するだけです!)。

ただし、最近のアプリケーションで提案しているものと同様の手法を使用しました。ここでは、キャッシュされたルックアップ データを使用して、返される DTO に説明の値を設定しました。テスト中に、これらの値を取得するために 10 以上のテーブルを結合する DB クエリよりも大幅に高速であることが判明しました。私が使用した検索データはめったに変更されませんでしたが、念のため 30 分後にキャッシュを期限切れにしました。

また、時期尚早の最適化と、実際には抱えていない問題を解決しようとする可能性についても意識する必要があると思います。

于 2013-08-05T15:57:02.547 に答える