DDデザインがあり、依存関係の注入も使用するプロジェクトがあります。開発中、本番環境の以前のスナップショットを含むテストデータベースに接続します。これは95%の確率でうまく機能します。ただし、アプリケーションに実装する必要がある一部のプロセスでは、基盤となるSQLステートメント(制御できないため、サードパーティによって開発されています)が遅くなります。これらの手順の一部は30秒かかる場合がありますが、実行に5分以上かかる場合もあります。
私たちのUIはこのデータに依存しており、残念ながら、ユーザーは、開始してデータが到着するまで待つ必要があるいくつかのタスクがあることを理解しています。現時点では、最終的なアプリケーションを高速化する方法は求めていません。簡単に言えば、私たちの制御の及ばない多くの要因があり、この制限は最終結果の一部として受け入れられる必要があります。
ただし、UIの開発中は、ドメインから結果を応答して返す必要があります。これを行うために、アプリケーションプロジェクト内に偽のリポジトリを設定しました。具体的には、AppHost
内のすべてのDIコンポーネントを初期化するASP.Netプロジェクトがあります。すべてのリポジトリがコンテナに注入され、続いてそれぞれのドメインがWebページUIで使用されるASP.Net APIで使用されると言われています。
これまでのところ、ASP.Netプロジェクト内から偽のリポジトリーを作成しています。 AppHost
内に、#ifdef FAKES
プリプロセッサは、偽のリポジトリを使用することを指定したかどうかを確認し、通常のテストや最終的に本番環境で使用される正当なものではなく、偽物をロードします。
この作品は感じています...間違っています。多分これは正しいアプローチかもしれませんが、偽のデータリポジトリをアプリケーションの開発用に注入するより良い方法が必要であるかのように感じます。この目的のためのより良い方法はありますか?
1つの要件は、開発中のこの偽のデータにalwaysにアクセスしたくないことです。 UIを構築している間、適切なデータ型と文字列の長さを持つものが存在する限り、データがどのように見えるかを気にすることはあまりありませんでした。ただし、実装をテストする時が来たら、正規のテストデータがテストサーバーから読み込まれるのを待つ必要があります。
明確にするために、これらの偽物ではないは単体テスト用です。このコンテキストでは、偽のリポジトリを厳密に作成しているため、2〜3分ではなく、ミリ秒単位でデータが返されます。これらのコンテキスト固有の開発偽物を実装およびロードするより良い方法はありますか?
あなたが提供したフィードバックを考えると、偽物の使用は完全に正当化されます。偽物と実際のデータをすばやく切り替えられるようにしたい場合は、DLLの存在によって引き起こされる偽物を利用することができます。
ソリューションは次のようになります。
動的読み込み機能全体をコードの#if DEBUG
セクション内に配置できるため、本番環境に移行しません。または、ロードするアセンブリの選択を、アプリケーションの起動後に読み込まれるパラメーターにすることもできます。これにより、再コンパイルせずに偽物をすばやく簡単に交換できます。
小規模なシステムでも有効な元の回答
2つのことを行うことをお勧めします。
高速な応答時間が必要な場合は、最小限のデータベースに接続してください。アプリケーションの正確性を検証する必要がある場合は、本番環境のバックアップに接続します。
クエリを制御できなくても、スキーマに影響を与えることができるはずです。本番環境のバックアップを使用すると、インデックスを慎重に追加して、クエリのパフォーマンスを向上させることができます。パフォーマンスが十分に向上している場合は、本番環境にプッシュしてください。