2

質問

個別のプロジェクト/アセンブリを使用せずに、あるカスタム タイプを別のカスタム タイプから非表示にするメカニズムが .NET Framework にありますか? Type のメンバーを別の型から非表示にするためのアクセス修飾子について話しているのではなく、Type 自体を非表示にすることを意味します。

バックグラウンド

私は ASP.NET Web サイト プロジェクトで作業していますが、チームはソフトウェア レイヤーごとに個別のプロジェクト アセンブリを使用しないことにしました。したがって、たとえば、クラスが同じ ASP.NET Web サイトプロジェクト内の他のタイプにアクセスできないようにする DataAccess/ フォルダーを作成する方法を探しています。言い換えれば、レイヤーを偽造し、各レイヤーの周りに何らかのセキュリティメカニズムを用意して、別のレイヤーにアクセスできないようにしたいと考えています。

詳細情報と詳細 ...

言語固有の OO キーワードを使用してこの制限を強制する方法がないことは明らかなので、別のものを探しています。ある名前空間が別の名前空間にアクセスするのを制限するものでさえ。それが最終的な形になるかどうかはわかりません。

これが C++の場合friend、解決策として make を使用する可能性が高く、この場合は C#internalに変換されませんが、よく比較されます。

ソリューションが実際にタイプを互いに隠しているのか、単にアクセスできないようにするのかはあまり気にしません。ただし、1 つのタイプを他のすべてのタイプからロックダウンしたくありません。これは、アクセス修飾子が解決策ではないもう 1 つの理由です。実行時または設計時の回答で十分です。それ以外の場合は、努力する価値がない実装が簡単なものを探しています...

4

2 に答える 2

3

NDepend を使用してこれを行うことができます。

http://www.ndepend.com/

NDepend を使用すると、特定の名前空間が相互に参照してはならないことを指定することで、「階層化」ルールを適用できます。次に、NDepend とルールセットを自動ビルドにプラグインすると、不正行為があった場合にビルドが失敗します (完全なレポートが表示されます)。

このようにして、プロジェクト構造を使用して物理的に実行する必要なく、アセンブリ内に論理的なソフトウェア レイヤー化の概念を適用できます。

アップデート

昨夜遅くに質問に答えましたが、文字通り、つまり、質問を直接解決する方法です。ツールを使用して問題を解決することはできますが、チーム全体で 1 つのプロジェクトを開発することは、プロジェクトが大きくなるにつれてかなり悲惨な経験になる可能性が高くなります。

  • 人々が信じられないほど訓練されていない限り、ビルドはレイヤー違反で壊れ続けます。
  • VS プロジェクト ファイルでソース管理のマージ スラッシングが発生します。これは好ましくありません。
  • 開発中の他のアプリケーションやプロジェクトとアセンブリを共有したい場合、再利用の単位は非常に大きく未定義です。これにより、非常に望ましくない結合が発生する可能性があります。

小さなアセンブリを多数持つことは推奨しませんが、「UI」、「データ アクセス」、「ビジネス ロジック」、「共通ライブラリ」、「共有型」などのコア コンセプトの周りに適切な数を定義することは、非常に実用的で望ましいことです。

于 2010-05-23T01:24:19.417 に答える
0

箱から出して何もありません。おそらく名前空間などに基づいて、いくつかのルールをまとめるために使用できるサードパーティのツールがあるかもしれません。カスタムfxcopルールのようなもの...

于 2010-05-22T23:55:05.523 に答える