究極のVisual Studioソリューション構造 質問する

究極のVisual Studioソリューション構造 質問する

これは現在のプロジェクトに基づいて主観的になる可能性があることを認識し、VS (Visual Studio) ソリューションを構成するための「ベスト プラクティス」の方法を探しています。

ぜひ自由に編集し、間違っていると思われる点についてコメントしたり、代替案を提案したりしてください。このコミュニティ Wiki が、VS ソリューションを始めたばかりの人々にとって素晴らしいリソースに成長していくことを願っています。

以下は、現在私が(現在のプロジェクトで)動作しているものですが、間違った場所にいくつかのものがあることは事実です。私のシナリオでは、ウェブアプリケーション使用して2 の

最終的なソリューション構造のアイデアを投稿してください。そうすれば、「最善の方法」/「ベストプラクティス」のアイデアを得ることができます。それが正確に何を意味するのかは

例えば:
DAL (データ アクセス層) / BLL (ビジネス ロジック層) をどのように分割しますか?
リポジトリ層とサービス層を BLL 内に配置しますか? MVC (モデル ビュー コントローラー) を使用している場合、コントローラーをコアではなく UI に保持しますか?
ユーティリティ/その他フォルダーに多くのものを入れますか、それともさらに細かく分割しますか?
など...


  • マイソリューション
    • マイソリューションコア
      • 認証
        • これはPOCOと、POCOを認証クッキーのuserDataセクションにシリアル化するメソッドがある場所です。
      • ベース
        • ここはBaseControllerとBaseGlobalを保存する場所です
      • コントローラー
        • 私のコントローラーすべて(当然ですが)
      • ドメイン
        • データベースモデル
          • L2S .dbmlファイルが含まれています
        • Jsonモデル
          • JSONオブジェクトをビューに渡すために使用されるモデル
        • リポジトリ
        • サービス
        • ビューモデル
      • 拡張機能
        • すべての拡張メソッド
      • フィルター
        • アクションフィルター
      • ユーティリティ
        • アピス
          • サードパーティのAPIコードはすべてここに入ります
        • バッジ
          • バッジの計算はここに記入します
        • メールクライアント
          • ここのクラスを使用してプレーンテキストまたはHTMLメールを送信します
        • ルーティングヘルパー
          • 小文字ルートを有効にするクラスが含まれています
        • また、他にどこに置けばよいかわからないものも含まれています...たとえば、HTMLSanitizer、カスタム HtmlHelpers、UserInfo ヘルパー (IP アドレス、ブラウザーなど)、DataConverter などです。
    • マイソリューション.UI
      • アプリ_ブラウザ
      • 資産
        • css
        • 画像
        • スクリプト
      • ビュー
      • グローバル.asax-BaseGlobalから継承
      • ウェブ.config

スクリーンショット
芯インターフェース

遠慮なくコメントしてください。あるいは、もっと良いのは、あなた自身のバージョン(回答)を以下に投稿することです。私が考えた方法が最善の方法ではないことはわかっています。

ベストアンサー1

素晴らしいウィキです。

私は新しいプロジェクトを始めており、これが私が始めた構造です。

これは、Microsoft のベスト プラクティス (ビジネス、データ、サービス、プレゼンテーション) に準拠しています。

代替テキスト

私の解決策では:

  • ビジネス: ドメイン/プロジェクト固有のロジック、特に POCO。
  • データ: リポジトリ。説明不要です。
  • サービス: リポジトリ上のロジック。ここでキャッシュやフィルタリングなどを追加できます。UI はリポジトリに直接ではなく、サービスを介してリポジトリと通信します (UI の 1 対 1 の依存関係)。
  • プレゼンテーション: MVC アプリケーション (TBD)。

実際のプロジェクト アセンブリ名の前に FQN を付ける習慣があることに気付くでしょう。

見た目が気に入っています。さらに、オブジェクト エクスプローラーではすべてが「ツリー状」にきれいに表示されます。

また、私はフォルダーの前に番号を付ける習慣があり、それによって「何に何が必要か」に従って並べ替えます。言い換えると、すべてがビジネス レイヤーに依存し (したがって最上位にあります)、リポジトリはビジネスのみに依存し、サービスはリポジトリとビジネスに依存し、プレゼンテーションはサービスとビジネスなどに依存します。

もちろん、上記は出発点です。現在私が持っているのは、ユーザーを返すリポジトリと、その上にロジックを適用するサービス (フィルタリング) だけです。

最終的には、ビジネス プロジェクト、リポジトリ (Web アプリケーションの論理領域ごとに 1 つ)、サービス (外部 API、統合) が増えることになりますが、もちろんプレゼンテーションには何もありません (TDD を実行しています)。

また、依存関係をすべて 1 か所 (プロジェクト フォルダー) にまとめておくのも便利です。

拡張機能については、プロジェクトごとに 1 つのクラス (Extensions.cs) があります。つまり、リポジトリを「拡張」したり、ユーザー サービスを「拡張」したり、一部の UI 機能を「拡張」したりしていることになります。

テスト プロジェクトの場合 - ソリューション プロジェクトごとにテスト プロジェクトがあります。

これが私の意見です(参考までに)。

おすすめ記事