近々、いくつかの Web アプリケーションを設計します。それらはおそらくasp.net mvcで行われます。
Delphi で作成した既存の Web アプリでは、データ アクセス レイヤーが完全に別のアプリケーションに分離され、別のサーバーで実行されることもあります。これは、アーキテクチャ上の理由よりも、コードの再利用のために行われます。これはすべて新しいものになるため、次のアプリの要因にはなりません.
MVC アプリで個別のデータ アクセス アプリケーションを使用するのはやり過ぎですか? MVC を使用してビジネス クラスを分離し、ORM を使用してデータベースの永続化を行います。
編集：明確にするために。階層という用語は、単なる論理的な分離やレイヤー以上のものである、別個の物理アプリケーションを指すために使用します。
私の経験では、「層」という用語は、通常、クライアント層とサーバー層などの物理的なアプリケーションの分離を指しています。
MVC -モデル (データ)、ビュー (UI)、コントローラー (アプリ ロジック) の詳細を示す 3 つの懸念事項の周りの分離に関する懸念がある 3 つの 「レイヤー」を参照します。
用語に関してその区別をしたので..
MVC アプリで個別のデータ アクセス アプリケーションを使用するのはやり過ぎですか?
いいえ（アプリケーションの意味にもよりますが）、実際にはより保守しやすいシステムになる可能性があるため、やり過ぎではありません。ORMでは、新しいデータ アクセス オプションをプラグインできる可能性がありますが、新しい ORM を追加したい場合はどうすればよいでしょうか? 明確に分離されたデータ アクセス レイヤー (DAL) を使用すると、アプリケーションのこの側面で将来の柔軟性が大幅に向上します。
一方、アプリケーションの規模とビジョンによっては、完全にスタンドアロンのデータ アクセス オプションを作成するのはやり過ぎかもしれませんが、一言で言えば、DAL を異なるアセンブリに分離することは、実装するアプリケーションの構成において非常に推奨される方法です。 MVC パターン。
これがお役に立てば幸いです。さらに詳細が必要な場合は、コメントしてください。
階層(物理)について話しているのか、層(論理/プロジェクト)について話しているのかによって少し異なると思います。
階層化について - s#arp アーキテクチャ ( code.google.com/p/sharp-architecture/ ) のようなものを見て、その方法の例を確認できます (階層化に対してかなり最大のアプローチを取っています)。
よりミニマルなビューの例については、Ayende のブログ ayende.com/Blog/ をご覧ください。
層について - 容量の理由でこれを行う必要がない限り、不必要に層を追加してすべてをネットワーク上に置くと、パフォーマンスに影響を与えると思います。レイヤーを正しく取得し、容量を調整する必要があるため、それらを階層に分離します (懸念事項を適切に分離した場合は、あまりリファクタリングを行うべきではありません)。
素晴らしいコメントトビアス。
私はそれがあなたにとって意味があり、維持しやすいように十分な層を追加すると言います。また、関心の分離を維持するため。