4

私が疑問に思っていたことですが、今まで尋ねるにはやや恥ずかしすぎます:「適切な」MVC (厳密にパターンに準拠している) では、すべてがモデル、ビュー、またはコントローラーである必要がありますか? そうでない場合、パターンを破ることが望ましい、または必要な場合の例を挙げていただけますか? 最後に、MVC におけるクラス (または静的) メソッドの役割は何ですか?

具体例: 私はモデルOneModelとTwoModel. それらが何らかのスーパークラスから継承されていると考える自然な理由はありません。どちらもまったく異なるプロパティを持っていますが、フィールドを共有しているので、モデルごとに共有しemailAddressたい場合があります。validateEmailAddress()各モデルの検証コードをコピーしたくないので、とのそれぞれで呼び出すValidationHelperクラス メソッドを使用してクラスを作成します。validateEmailAddress(String emailAddress)OneModelTwoModel

私は今パターンを壊しましたか？どうすれば修正できますか？

4

3 に答える 3

1

MVC はアーキテクチャ パターンであることを理解する必要があります。そのため、コンポーネントがどのように編成され、相互に作用するかを説明する高レベルのパターンです。この編成を実現するには、「面倒な作業」を行う特殊なコンポーネントのセットが必要になります。このセットには、おそらくどの文字 MVC の定義にも当てはまらないコンポーネントがいくつかあります。一部のコンポーネントは機能を支援するだけであり、他のコンポーネントはレイヤー間のインターフェース上にあり、それらの統合に取り組んでいます。

したがって、答えはノーです。すべてがモデル、ビュー、またはコントローラーではありません。

于 2013-05-20T18:59:13.007 に答える
1

MVC 設計パターンは、次の 2 つの主要部分で構成されています。

  • プレゼンテーション層
  • モデルレイヤー

プレゼンテーション層は、ユーザーがモデル層と対話する方法を提供し、モデル層にはすべてのビジネス ロジックと関連するタスクが含まれます。

モデルはクラスでもオブジェクトでもありません。代わりに、いくつかの構造グループが含まれており、それぞれがドメイン ビジネス ロジックのさまざまな側面を担当しています。詳細な説明はこちらでご覧いただけます。

プレゼンテーション レイヤーは、モデル レイヤーとの対話方法に基づいて大部分が分割されます。コントローラーは (サービスを介して) モデル レイヤーに「書き込み」、ビューはそこから「読み取る」と言えます。

MVC 設計パターン全体 (およびその他の MVC にインスパイアされたパターン) の中で最も単純な部分はコントローラーであるべきです。それらはユーザー入力を受け取り、それに基づいてモデルレイヤーの状態を変更します。ビューを変更することもできますが、MVC が Web に適用されると、ルールというよりも例外になります。

ビューに関しては、私はまだそれらを理解しようとしています。私が現在得ているものはここで読むことができます。

注: Web に適用する場合、ビューの実装に関する資料が大幅に不足しています。プラットフォームが全く違うので、デスクトップアプリと比べると、同じガイドラインをそのまま移植することはできません。また、Web 用のビューの作成に焦点を当てた、このテーマに関するフレームワークに関係のない資料は見つかりませんでした。

于 2013-05-19T13:08:35.493 に答える