1

ファイルシステムの抽象化を提供して、ファイルの読み取り、ディレクトリの作成などの IO 操作が、特定のファクトリを介して取得された特定の実装に対して常に実行されるようにするプログラムがあります。

たとえば、System.IO.File にアクセスする代わりに、システムでサポートされているファイルに対する特定の操作セットを含む MyLib.IO.File にアクセスする必要があります。実際の実装は、IOC またはシングルトン ファクトリによって提供されます。 .

ただし、システムに不慣れな人は、System.IO を参照するだけで、ファイル システム内のファイルを直接操作し始める可能性があります。彼の実際の構成が標準の System.IO ラッパーをインスタンス化する場合、彼のマシンではすべて正常に動作しますが、基礎となるファイル システムが変更されると、最終的には機能しなくなります。

VSアプリケーションで特定の名前空間の使用を警告したり、禁止したりする方法はありますか?ユーザーは、.NETフレームワークのその部分を使用するべきではなく、その特定の機能を取得するために提供される別のライブラリを使用する必要があることを認識できますか?

4

3 に答える 3

2

はい。明確で短い API ドキュメントと呼ばれる方法があります。読むことを奨励するのに十分明確であり、開発者が終了する前に放棄することに興味を持たないようにするのに十分短い.

独自のライブラリの使用を強制することは悪くないように聞こえますが、議論はありますが、BCL ライブラリを曖昧にすることはかなり悪いように聞こえます。

于 2012-09-24T23:31:12.870 に答える
1

CASPOL は煩わしく、行き詰まるまで API ドキュメントを読む開発者は多くありません。

System.IO などの不要な参照について、アセンブリ バインディング ログ ビューアー (Fuslogvw.exe) を使用してソリューションに問い合わせるビルド スクリプトをリリースします。さらに進んで、リフレクションまたはイントロスペクションを使用して、System.IO の使用が適切かどうかを確認することもできます。私見では、このオプションは最も邪魔にならず、リリースに正しい DLL/名前空間が使用されることを保証します。

于 2012-09-24T23:42:39.993 に答える
0

いいえ、ありません。

編集：

まあ、多分。の使用は、System.IO.*コード アクセス セキュリティ (または .NET 4.x での代替手段) を使用して制限できますが、これは、アプリケーションを完全に制御する必要があることを意味します (たとえば、単に別のプログラムを使用するのではなく、アドイン コードをロードする必要があります)。組み立て）。

于 2012-09-24T23:25:36.977 に答える