従来の MVC アプリケーションでは、どのコンポーネント (モデル、ビュー、またはコントローラー) がモデルのディスクへの読み取り/ディスクからの書き込みを担当していますか?
6 に答える
簡単な答え:モデル層。
ストレージのほとんどの形式は、モデル レイヤーの一部です(クラスのテンプレートとオートローダーを除く)。完全に実現されたモード レイヤーでは、低レベルのストレージ (SQL、キャッシュ、REST API、noSQL、ファイル システムなど) の抽象化と直接対話するオブジェクトのグループがあります。
アプリケーションがファイルシステムに対してアクティブに読み書きしている場合 (実際には、SSH トンネルを介して Fuse 経由でマウントしたリモート MemoryFS にマウントされている可能性があります。問題ありません)、これはストレージ ロジックを処理する構造体によって処理されます。通常、何らかの形式のデータ マッパー(リポジトリ、作業単位、DAO、および/または同様の構造である可能性も考えられます)。
通常、ストレージの抽象化は、ドメイン オブジェクトからのデータの格納とドメイン オブジェクトへのデータの取得を担当します。大規模なアプリケーションでは、ドメイン オブジェクトとストレージ ロジック構造の間のこの相互作用は、アプリケーションとドメインのビジネス ロジックがプレゼンテーション レイヤーでリークするのを防ぐために、サービス内に含まれています。
他の人が投稿したように、通常、MVCアプリの下にドメイン/ビジネスレイヤー/データレイヤーがあります。Entity Frameworkを使用してこのようなスタックを実装する方法の良い例をいくつか探している場合は、NerdDinnerとMVCMusicStoreの例を確認してください。
MVC
は通常、プレゼンテーション ベースのアプリケーションの最上位に位置するプレゼンテーション レイヤー フレームワークです。実際のエンタープライズ アプリケーションでは、その下にいくつかのレイヤーがある場合があります。
Business Layer
通常、これは別のレイヤーで行われます:またはのように名前を付けることができService Layer
ます。
「レイヤー」とアーキテクチャー・パターンに関しては、多少の複雑さと大きな混乱があります。最も単純な答えを探していて、単純化のためにコードの各部分が (モデル、ビュー、またはコントローラー) の 1 つだけにあると決めた場合、私の答えは次のとおりです。データベース アクセスのモデル。現実には、すべてのアーキテクチャ パターンは不完全であり、何が正しいと感じるかを経験で確認する必要があります。
MVC は、より大きなアーキテクチャの一部にすぎません。
永続性などのインフラストラクチャの問題は、通常、MVC トライアドの外部にあるいくつかのクラス/オブジェクトによって処理されます。
mvc にディスク io が存在する必要はありません。存在する場合、それが永続化されている場合は、おそらくモデル内またはモデルの近くに属しています。