c# - 中規模のWebアプリケーション用のリポジトリを備えたLinqtosql

Question

Linq to Sqlの上にリポジトリパターンの実装を作成することは、中規模のパブリックフェイスのWebアプリケーションに適した設計ですか？

アプリはSQLサーバーバックエンドのみを扱い、迅速な開発が必要です

LINQ2SQLはきちんとしたDALなので、私は本当に好きです。EFのことを考えましたが、このプロジェクトには多すぎます。

提案を事前に感謝します。

Answer 1

コメントで与えられたあなたの質問に答える：そのようなリポジトリはあなたに何をもたらしますか？L2Sはすでに「リポジトリ」です。答えはおそらくノーです。

ORマッパーを交換するのは何回ですか？それは決して起こりません。もしそうなら（それは非常にありそうもないですが）、とにかくアプリ全体をレビューして再テストする必要があります。ORMを抽象化することは、常に非常に高い価格を支払うことによって、非常にありそうもないコストを防ぐことです。良い取引ではありません。

Answer 2

リポジトリパターンの元となるDDDの大きな信条は、その存続期間にわたって「簡単に」進化できるアプリケーションを作成することです。将来的には、Linq2Sqlがニーズに不十分である、または（より可能性が高い）テクノロジーが廃止された（Linq2SqlがEFを支持するため）などに気付く可能性があります。リポジトリパターンを使用すると、堅実でよく知られた概念、抽象的な方法で。実際の実装は、さまざまなアプリケーション機能から隠されています。つまり、将来、必要に応じてそれらを交換することができます。

リポジトリを使用するコンポーネントを環境とは独立して使用できるようにするなど、他にも利点があります。リポジトリを使用するコンポーネントがあり、夜間のジョブを実行するには、サービスでこのコンポーネントを使用できる必要があることがわかったとします。同じコードを使用するサービスを作成できますが、データベースではなく、Webサービスと対話するリポジトリの実装を使用します。あなたは一度コードを書いた、ただいくつかのスイッチを入れた。

もう1つの大きな理由は、単体テストです。ORMまたは永続性APIが機能することを単体テストする必要はありません。そうでなければ、永続性と相互作用するアプリケーションが期待どおりに機能することを単体テストする必要があります。

そうそう、いいデザインだと思います。

Answer 3

むしろEF、v4.1以降を使用し、リポジトリパターンをスキップします-常にdbにアクセスし、常にmsSQLにアクセスします。