web-dev-qa-db-ja.com

コントローラーにはMVCのgetメソッドが含まれていますか？

私はモデルとコントローラーを開発した後、初めてのビューを実装する段階にありますが、問題があります。

私は読んでいます MVCに関するこの記事 、これは実装時に目指していたものですが、コントローラーを作成するときは、振り返ることを覚えていなかったので、スクリプトから外れました、それだけの助けになったとは思いません。

現在、私のコントローラーにはメソッドが含まれています：

    public function add($name, $price, $dimensions): string

    public function remove($sku): void

    public function removeAll(): array

    public function updatePrice($sku, $price): void

しかし、Viewを作成するとき、コントローラーにモデルからのデータを要求しない限り、エンティティーをリストするためにデータベースアクセスを実装する必要があることに気付きます。それは私には一種の間違っているように見えますが、上記の記事のいくつかの説明を考えると、これは必要なようです。

すでにデータベースにアクセスしているクラスから「取得」機能を提供することは、私には最もきちんと思われます。要するに、ビューはデータベースと直接インターフェースすべきですか？

databaseviewcontroller
2
Scott Anderson

真の [〜＃〜] mvc [〜＃〜] の場合、コントローラーはユーザーから入力を受け取り、ビューを制御するためのコマンドに変換します（たとえば、新しいビューを作成するか、ビュー）またはモデルの場合（例：価格の更新、変更の保存など）。

説明するメソッドはコントローラーではなくモデルに属します。価格付きアイテムの追加、価格の更新、在庫管理単位（SKU）の削除、およびすべてのアイテムの削除は、モデルの責任です。あなたの記事を引用するには：

モデルは、設計全体で使用されるデータの永続的なストレージに付けられた名前です。データを表示または収集して書き込むためのアクセスを許可する必要があります（...）
コントローラーは、情報のコレクターとして単純にまとめることができ、それをモデルに渡して保存用に編成します。入力を収集するために必要なもの以外のロジックは含まれていません。 （...）
開発者が犯す最も一般的な間違いは、コントローラーをゲートウェイと混同することです（...）

そのため、コントローラはデータベースへの単なるゲートウェイではありません。すべてのデータベース相互作用はモデルに属します。コントローラーとビューはデータベースについて何も認識していません。それらはモデルについてのみ認識しています。

追加備考：

上記の原則をすべて共有するいくつかのMVCバリアントがあります。あなたの記事では、ビューごとに1つのコントローラーがあります。

ORMは、オブジェクト（アプリケーション）とテーブル（データベース）の間のマッピングを作成し、 データベースへのアクセス を容易にします。 MVCアーキテクチャでは、ORMを使用してモデルを実装します。モデルを置き換えることはできません。

アーキテクチャが異なれば、責任の配分も異なる場合があります。しかし、それはもはやMVCではありません。

  • コントローラーがビューとモデルの間の仲介者として機能し、ビューがコントロールレンズをクエリする場合、コントローラーはおそらくコントローラーではなく [〜＃〜] mvp [〜＃〜] のプレゼンターです。
  • ビューに、コントローラーを介してモデルと同期されるデータバインディングがさらにある場合、それはおそらくコントローラーではなく、 [〜＃〜] mvvm [〜＃〜] のビューモデルです。
  • モデルにないビジネスロジックとデータベースの責任がコントローラーにある場合は、MVCで何か問題があったか、またはコントローラーが実装するアーキテクチャについて誤解があります EBCパターン 別の目的があります。
4
Christophe

「MVCはかなり抽象的なガイドラインです。」すべての状況がそれに準拠しているわけではありません。 、「それらのどれもしない」と言うでしょう。しかし、（少なくとも、私にとっては）それは実際には大丈夫です。それにもかかわらず、本当の肉とじゃがいものための一般的な戦略として、「それにもかかわらず、一般的なアイデアは有用です」：「懸念の分離」

0
Mike Robinson