8

複数の PHP フレームワーク、特に Zend Framework について調べてきましたが、適切な進め方について混乱しています。

Zend Framework は ActiveRecords を使用しませんが、代わりにテーブル データ ゲートウェイと行データ ゲートウェイ パターンを使用し、DataMapper を使用して行データ ゲートウェイの内容をモデルにマップします。これは、モデルに 1 がない場合に ActiveRecord が機能しなくなるためです。データベース テーブルへの 1 つのマッピング。Zend クイックスタート ガイドにこの例があります。

私には、彼らの例は、いたるところにたくさんのゲッターとセッターがあり、非常に肥大化しているように見えます。ドメイン駆動設計に関するさまざまなブログ投稿に出くわしました。非常に多くのゲッターとセッターを使用することは、すべての内部モデル データを外部に公開するため、悪い習慣であり、パブリック属性よりも利点がないと主張しています。ここに一例があります。

私の質問: これらのゲッターとセッターを削除すると、どのようにビューをレンダリングしますか? 実際にユーザーに何かを表示できるように、ある時点でデータがビューにヒットする必要があります。DDD のアドバイスに従うと、MVC での M と V の分離が崩れるようです。MVC と Zend の例に従うと、DDD が壊れているようで、すべてのモデルに対して大量のゲッター、セッター、および DataMappers を入力する必要があります。大変な作業であるだけでなく、DRY にも違反しているようです。

いくつかの (へのリンク) 良い例、またはすべてがどのように適合するかについての詳細情報をいただければ幸いです。ここでアーキテクチャとデザインのスキルを向上させようとしています。

4

5 に答える 5

2

すべてのゲッター/セッターを実装する必要はありません。__get() と __set() を使用できます。じゃあ何が問題なの？

于 2009-06-20T22:45:36.427 に答える
2

値オブジェクトを使用すると、これらのパブリック セッター メソッドの一部を削除できます。Entity と Value Objects の違いについて説明します。値オブジェクトは不変であり、エンティティに結び付けられることがよくあります。コンストラクターですべての値を渡す場合、これらのプロパティを外部コードから設定する必要はありません。

答えに直接関係するものではありませんが、DDDに焦点を当てた追加の何か：

(免責事項: Zend Framework について私が知っていることは、リンクされた記事で読んだことだけです。) Zend Framework は、リポジトリの代わりに DataMappers を使用しています。これは本当にDDDっぽいですか？まあ、Fowler のリポジトリの解釈はノーと言うかもしれません。しかし、Eric Evans は、DDD リポジトリは非常に単純になり得ると述べています。最も単純なリポジトリはDataMapper です (DDD の本を参照)。より複雑でなおかつ DDD については、Fowler の記事を参照してください。DDD には、パターン定義とは異なる可能性がある概念的なリポジトリがあります。

ドメイン駆動設計について引き続きお読みください。ゲッターとセッターが DDD に違反しているという仮定には欠陥があると思います。DDD は、ドメイン モデルとそれを達成するためのベスト プラクティスに焦点を当てています。アクセサーはほんの些細なことです。

于 2009-06-23T18:06:30.633 に答える
1

ここには 2 つのアプローチがあります。私が「Tell Don’t Ask アプローチ」と呼んでいるものと、もう 1 つは ViewModel/DTO アプローチです。基本的に、質問はあなたの見解における「モデル」とは何かを中心に展開します。Tell don't askでは、オブジェクトを外部化できる唯一の方法は、オブジェクト自体からである必要があります。つまり、オブジェクトをレンダリングするには render メソッドが必要ですが、その render メソッドはインターフェイスと通信する必要があります。このようなもの：

class DomainObject {
   ....
   public function render(DomainObjectRenderer $renderer) {
        return $renderer->renderDomainObject(array $thegorydetails);
   }
}

Zend Framework のコンテキストでは、Zend_View をサブクラス化し、サブクラスにこのインターフェイスを実装させることができます。

これは前にやったことがありますが、少し扱いに​​くいです。

2 番目のオプションは、ドメイン モデルを ViewModel オブジェクトに変換することです。これは、特定のビューごとに (ビューごとに 1 つの ViewModel を使用して) カスタマイズされた、単純化され、フラット化され、「文字列化された」データのビューのようなものです。 、POST データを EditModel に変換します。

これは、ASP.NET MVC の世界で非常に一般的なパターンですが、アプリケーションの「レイヤー」間でデータを転送するために使用されるクラスの「DTO」パターンにも似ています。面倒な作業を行うには、マッパーを作成する必要があります (実際には、DataMapper とは異なります)。PHP 5.3 では、リフレクションを使用してプライベート プロパティを変更できるため、DomainObject 自体を公開する必要さえありません。

于 2009-11-09T21:26:31.887 に答える
1

投稿を読んだところ、質問は実用的というよりも哲学的です。

詳細を書く時間はありませんが、ここに私の 2 セントを示します。クラスはその内部を非表示にする必要があるため、get および set リクエストの数を制限したいという意見には同意しますが、Java と PHP は異なるツールであり、異なる目的を持っていることも考慮する必要があります。Web 環境では、リクエストごとにクラスが構築および削除されるため、作成するコードは巨大なクラスに依存するべきではありません。あなたが指摘した記事では、著者はビューロジックをクラスに配置することを提案しています。ビューを複数の形式 (rss、html など) で表示したい可能性が高いため、これはおそらく Web では意味がありません。したがって、アクセサー メソッド (get & set) を使用することは必要悪です。自分の足を撃たないように、慎重に使用する必要があります。重要なのは、クラスに外部から仕事を強制しようとするのではなく、クラスに仕事をさせようとすることです。直接ではなくメソッドを使用してプロパティにアクセスすることにより、必要な内部を非表示にします。

繰り返しますが、この投稿ではいくつかの例を使用できますが、今は時間がありません。

他の誰かがアクセサメソッドが悪ではない理由のいくつかの例を提供できますか?

于 2009-06-22T19:31:58.730 に答える
0

ゲッターとセッターの実装には、私の目には 2 つの利点があります。

  1. 公開するプロパティを選択できるため、必ずしもモデルの内部構造をすべて公開する必要はありません。
  2. オートコンプリートを備えた IDE を使用している場合、「get」または「set」と入力し始めると、使用可能なすべてのプロパティが TAB で表示されます。これだけでも十分です。
于 2009-07-09T21:42:01.173 に答える