このアーキテクチャでOOPプラクティスを破っていますか？
Webアプリケーションがあります。テクノロジーが重要だとは思わない。構造は、左の画像に示されているN層アプリケーションです。3つの層があります。 UI（MVCパターン）、ビジネスロジックレイヤー（BLL）およびデータアクセスレイヤー（DAL） 私が抱えている問題は、ロジックとアプリケーションイベントコールを介したパスがあるため、BLLが非常に大きいことです。 アプリケーションの一般的なフローは次のとおりです。 UIで発生したイベントは、BLLのメソッドにトラバースし、ロジック（おそらくBLLの複数の部分で）を実行し、最終的にDALに戻り、BLLに戻り（さらにロジックが高い場合）、UIに値を返します。 この例のBLLは非常に忙しいため、これを分割する方法を考えています。また、ロジックとオブジェクトが組み合わされており、それらは好きではありません。 右側のバージョンは私の努力です。 ロジックは依然としてアプリケーションがUIとDALの間を流れる方法ですが、おそらくプロパティはありません...メソッドのみ（このレイヤーのクラスの大部分は、状態を格納しないため、静的である可能性があります）。Pocoレイヤーは、プロパティ（名前、年齢、身長などが存在するPersonクラスなど）を持つクラスが存在する場所です。これらはアプリケーションのフローとは関係なく、状態のみを保存します。 フローは次のとおりです。 UIからトリガーされ、UIレイヤーコントローラー（MVC）にデータを渡します。これにより、生データが変換され、pocoモデルに変換されます。その後、pocoモデルはLogicレイヤー（BLL）に渡され、最終的には途中で操作される可能性のあるコマンドクエリレイヤーに渡されます。コマンドクエリレイヤーは、POCOをデータベースオブジェクトに変換します（ほぼ同じものですが、1つは永続化用に設計され、もう1つはフロントエンド用に設計されています）。アイテムが保存され、データベースオブジェクトがコマンドクエリレイヤーに返されます。その後、POCOに変換され、そこでロジックレイヤーに戻り、さらに処理され、最後にUIに戻される可能性があります 共有ロジックとインターフェイスは、MaxNumberOf_XやTotalAllowed_Xなどの永続データとすべてのインターフェイスを保持する場所です。 共有ロジック/インターフェイスとDALの両方が、アーキテクチャの「ベース」です。これらは外の世界について何も知りません。 共有ロジック/インターフェースとDAL以外のすべてがpocoについて知っています。 フローはまだ最初の例と非常によく似ていますが、各レイヤーが1つのこと（状態、フロー、その他）に責任を負います...しかし、このアプローチでOOPを壊していますか？ LogicとPocoをデモする例は次のとおりです。 public class LogicClass { private ICommandQueryObject cmdQuery; public PocoA Method1(PocoB pocoB) { return cmdQuery.Save(pocoB); } /*This has no state objects, only ways to communicate with other layers such as the cmdQuery. Everything else is just …