分離された ASP.NET Web アプリケーションには複数のアセンブリを使用する必要がありますか?

Question

企業の IT 環境からの標準では、各レイヤー、ビジネス ロジック、データ アクセス、および場合によっては特定のタイプの分離を強化するためにクラス ライブラリ プロジェクトを常に作成していました。

現在、私は独自の Web アプリケーション プロジェクトに取り組んでいますが、この方法でコードを分離する実際の必要性は感じていません。

このロジックを共有する必要がある複数のアプリケーションや、それを有効にするサービスはありません。また、展開シナリオに利点があるとも思えません。

私は、すべてのアーティファクトを 1 つの Web アプリケーションに配置し、プロジェクト フォルダーによって論理的に分離することに傾いています。

コミュニティがどのような考えを持っているのか知りたかったのです。

---

さらに情報を追加させてください...

私は MVC プレビュー 5 を使用してこのアプリケーションを作成しているため、単体テスト部分はフレームワーク内で継承される懸念の分離によってサポートされます。私は何でもテストするのが好きです!

Answer 1

可能な限り単純なものから始めて、必要に応じて複雑さを追加します。あなたのケースでは単一のアセンブリがうまく機能するように思えます。ただし、レイヤー A がレイヤー B の内部メンバーにアクセスすることでレイヤーを侵害しないように注意してください。これにより、後でレイヤーを個別のアセンブリに取り込むことが困難になります。

Answer 2

それは、テストと単体テストに対してどれだけ真剣に取り組んでいるかによると思います。

ユーザー/手動テストのみを実行する予定がある場合、または基本的に UI から下方向のテストのみを使用する場合は、実際には違いはありません。

一方、ある種の単体テストやビジネス ルールの検証を行う予定がある場合は、作業をさまざまなアセンブリに分割することが明らかに合理的です。

小規模な個人プロジェクトであっても、このアプローチにより、プロジェクトが進行するにつれて作業が楽になることがわかりました。私は依然として、UI 用の Web プロジェクト、ビジネス ルール/アプリケーション ロジック用のライブラリ、および DAL 用の別のライブラリを使用して、同じソリューションからすべてを実行しています。

Answer 3

それでも、論理的にレイヤーを適切なプロジェクトに分割する必要があります。

これは、開発者が 1 人であろうと 100 人であろうと、エンジニアリングの良い実践です。コードを 1 か所にまとめた場合のマイナス点は、拡張のためにコードをリファクタリングしたり複製したりする必要があることです。