企業の IT 環境から生まれた標準は、常に各レイヤー、ビジネス ロジック、データ アクセス、および場合によっては特定の型のより大きな分離に対してクラス ライブラリ プロジェクトを作成することでした。
現在、自分の Web アプリケーション プロジェクトに取り組んでいるので、この方法でコードを分離する必要はないと思います。
このロジックを共有する必要がある複数のアプリケーションやサービスを有効にする必要はありません。また、展開シナリオに利点はないと思います。
私はすべての成果物を 1 つの Web アプリケーションに配置し、プロジェクト フォルダーで論理的に分離することに傾いています。
コミュニティの考えを知りたかったのです。
さらに情報を追加させてください...
私は MVC プレビュー 5 を使用してこのアプリケーションを作成しているため、単体テストの部分は、フレームワーク内の懸念継承の分離によってサポートされます。私はすべてのテストが好きです！
可能な限り単純なものから始めて、必要に応じて複雑さを加えてください。あなたのケースでは、単一のアセンブリで問題なく機能するように思えます。ただし、レイヤー A がレイヤー B の内部メンバーにアクセスすることによって、レイヤーに違反しないように注意してください。これにより、後でレイヤーを個別のアセンブリにプルすることが難しくなります。
それは、テストと単体テストについてどれだけ真剣に取り組んでいるかによると思います。
ユーザー/手動テストのみを行う予定の場合、または基本的に UI から下方へのテストのみを使用する場合は、実際には違いはありません。
一方、ある種の単体テストやビジネス ルールの検証を計画している場合は、作業をさまざまなアセンブリに分割することは間違いなく理にかなっています。
小規模な個人プロジェクトであっても、プロジェクトが進行するにつれて、このアプローチが私の生活を楽にしてくれることがわかりました。UI用のWebプロジェクト、ビジネスルール/アプリケーションロジック用のライブラリ、およびDAL用の別のライブラリを使用して、同じソリューションからすべてを実行しています。
論理的にレイヤーを適切なプロジェクトに分割する必要があります。
これは、1 人の開発者であろうと 100 人の開発者であろうと、優れたエンジニアリング プラクティスです。コードを 1 か所にまとめることのマイナス点は、拡張のためにコードをリファクタリングまたは複製する必要があることです。