私の会社で議論が起こっています。ビジネス、データ、およびビジネス エンティティを 1 つのアセンブリに移動することを提唱する人もいます。
- 見つけやすさの目的。探しているものを簡単に見つけられるようにします。
- 開発のためにプロジェクトに追加する必要がある dll の数を減らす
アプリケーション アーキテクチャ ガイドを引用している他の人は、各レイヤーとビジネス エンティティを個別のアセンブリに入れたいと考えています。
その点に注意してください
- 当社のビジネス層とデータ層はどちらも com + コンポーネントで構成されています。
- 現在のハードウェア アーキテクチャでは、Web、ビジネス、データが同じボックスに収められています。
- 別のボックスの SQL。
- とにかくcom+ではほとんど役に立たないため、現在dllのバージョン管理を使用していません。
一部の使用者は、ビジネス、データ、およびエンティティを分割する必要があるという直感を持っていますが、理由が不足しています.
- 潜在的にメモリ消費を減らす
- ビジネス レイヤー アセンブリのみを Web プロジェクトに追加することで、適切なアーキテクチャを奨励します。データサービスも利用できる場合、間違った方法で簡単に実行できます
- Web サーバーをビジネス層とデータ層から分離すると、ゴッド アセンブリから不要ながらくたをインストールする必要がなくなります。
現在、システムには約 600 個の dll があります。したがって、私たちはすべてが分割されている極端なところにいます。間違いなくいくつかの統合が行われる可能性がありますが、提案されていることは、すべてのアプリケーションが 1 つの dll にあるという完全に別の極端に私たちを連れて行こうとしています。
この一般的な問題について外部の視点を得ることができますか?
ありがとう！