2

ソリューション内のインターフェイスサブプロジェクトの命名規則はどうなるのだろうかと思っていました。インターフェイスファイルが「I」で始まることは知っていますが、これはプロジェクトにも当てはまりますか？

インターフェイスを実装するプロジェクト内にインターフェイスファイルを作成するのではなく、ソリューションを整理するために、インターフェイスを別のプロジェクトに分割しました。

すべてのファイルとプロジェクトが1つのソリューションに含まれています。

よく読めない場合はお詫び申し上げます。

4

4 に答える 4

3

これは、多くのプロジェクトでソリューションを編成するための一般的なパターンです。ただし、（場合によっては）それだけの価値があるかどうかについては議論があります。

いくつかの異なる命名規則が使用されているのを見てきました。

  1. Inc.Project.Contract
  2. Inc.Project.Contracts
  3. Inc.Project.Interface
  4. Inc.Project（一般的な依存関係であるベースプロジェクトのような）
  5. Inc.Project.Common
于 2012-07-04T14:18:57.897 に答える
1

これはMSがそれを使用する方法です<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

たとえば、Microsoft.WindowsMobile.DirectX.リンクhttp://msdn.microsoft.com/en-us/library/ms229026.aspxを参照してください。

于 2012-07-04T14:20:42.407 に答える
1

私はdtryonがその答えに書いた命名規則に同意します。

ただし、ソリューションの設計を過度に設計しないでください。複数のプロジェクトからインターフェイスを参照する必要がない場合は、インターフェイスを独自のプロジェクトに分離することは有用ではないと思います。複雑さが増しますが、メリットはほとんどありません。

インターフェイスファイル自体についても同じことが言えます。インターフェイスタイプ（実際にインターフェイスを実装するオブジェクトのタイプではない）を使用してオブジェクトインスタンスを参照する予定がない場合、インターフェイスはあまり役に立ちません。

于 2012-07-04T14:41:44.020 に答える
0

私は通常、次のパターンに従います...

  1. MyAppSolution-空のソリューション
  2. MyApp.App-クライアント向けアプリケーション
  3. MyApp.Adapters-インターフェースを含むプロジェクト
  4. MyApp.DAL-データアクセス層

それは通常私が作るのと同じくらい簡単です...物事がもっと複​​雑な場合、私はサービスプロジェクトやビジネスルールプロジェクトまたはそのような性質のものを持っているかもしれません...私がインターフェースプロジェクトを使用する理由は私がクライアントアプリケーションが欲しいからですバックエンドの実装を完全に知らないこと。そうすれば、実装を変更する必要がある場合でも、インターフェイスを変更しない限り、クライアントは影響を受けません（変更する必要はありません）...そして、これは実際に起こります...以前にDBMSを変更したことがあります。 DBMSからAPIなどに変更されました...最初にアプリを構築するとき、抽象化の余分なレイヤーは、必要になるまでやり過ぎのように見えることがあります。

于 2018-12-01T15:37:30.780 に答える