1

私は Yii フレームワークを使い始めて、「眠れない」ものを見ました。ここでは、Yii ユーザーが Active Record をどのように使用しているかについて、私の疑問について話します。

Giiによって生成されたのと同じように、多くの人がアプリケーションのビジネス ルールを Active Record に直接追加するのを見てきました。これは Active Record の誤解であり、SRPに違反していると確信しています。

初期の段階では、SRP の方が簡単に適用できます。ActiveRecord クラスは、永続性、関連付けなどを処理します。しかし、少しずつ、彼らは成長します。本質的に持続性を担うオブジェクトは、すべてのビジネス ロジックの事実上の所有者にもなります。そして 1 年か 2 年後には、500 行を超えるコードと、パブリック インターフェイスに数百のメソッドを含む User クラスが作成されます。コールバック地獄が続きます。

そのことを何人かの人に話したら、私の意見が批判されました。しかし、尋ねられたとき：

また、Gii を使用してビジネス ルールでいっぱいの Active Record を再生成する必要がある場合は、どうすればよいでしょうか? リライト？コピーアンドペースト？おめでとうございます！

答えを得た、沈黙だけ。

だから、私：

もう少し優れたアーキテクチャに到達するために私が現在行っていることは、フォルダ /ar にアクティブ レコードを生成することです。/models フォルダー内にドメイン モデルを追加します。

ちなみに はビジネス ルールを所有するドメイン モデルであり、アクティブ レコードを使用してデータを保持および取得するドメイン モデルであり、これがデータ モデルです。

このアプローチについてどう思いますか？どこか間違っている場合は、厳しく批判する前に理由を教えてください。

4

2 に答える 2

1

この記事のコメントの一部は非常に役立ちます: http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/

特に、厳密に「ファット モデル」のセットアップからモデルを成長させて、より多くのモデルが必要になるという考えは、非常に賢明に思えます。

現在問題を抱えていますか、それとも主に前もって計画しようとしていますか? これは前もって計画するのが難しいかもしれませんし、リファクタリングが必要になるかもしれません...

編集：

（以下のコメントで）に関してmoveUserToGroup、私はそれがあなたをどのように悩ませるかを見ることができました. あなたの質問について考えていたときにこれを見つけました: https://gist.github.com/justinko/2838490あなたが使用できる同等のセットアップmoveUserToGroupはCFormModelサブクラスです。検証などを行う機能を提供しますが、処理しようとしているものにより具体的になる可能性があります (目的を達成するために、1 つだけではなく複数の AR オブジェクトを使用します)。

私はよくCFormModelを使用して、複数の AR オブジェクトを持つフォームや、他のことをしたいフォームを処理します。

それがあなたが求めているものかもしれません。詳細はこちら: http://www.yiiframework.com/doc/guide/1.1/en/form.overview

于 2013-09-04T03:23:53.670 に答える
1

Martin Fowler による Active Record の定義:

オブジェクトは、データと動作の両方を運びます。このデータの多くは永続的であり、データベースに保存する必要があります。Active Record は、ドメイン オブジェクトにデータ アクセス ロジックを配置する最も明白なアプローチを使用します。このようにして、すべての人がデータベースとの間でデータを読み書きする方法を知っています。

データと動作を分離すると、Active Record がなくなります。関連する 2 つの一般的なパターンは、Data Mapper と Table/Row Gateway (これは RDBMS に関連しています) です。

再び、ファウラーは次のように述べています。

Data Mapper は、インメモリ オブジェクトをデータベースから分離するソフトウェアのレイヤーです。その役割は、2 つの間でデータを転送し、それらを互いに分離することです。Data Mapper を使用すると、メモリ内オブジェクトはデータベースが存在することさえ知る必要がありません。SQL インターフェースのコードは必要なく、データベース スキーマの知識もまったく必要ありません。

そしてまた：

テーブル データ ゲートウェイは、単一のテーブルまたはビューにアクセスするためのすべての SQL (選択、挿入、更新、および削除) を保持します。他のコードは、データベースとのすべての対話に対してそのメソッドを呼び出します。

行データ ゲートウェイは、レコード構造のレコードとまったく同じように見えるオブジェクトを提供しますが、プログラミング言語の通常のメカニズムでアクセスできます。データ ソース アクセスのすべての詳細は、このインターフェイスの背後に隠されています。

通常、データ マッパーはストレージに依存せず、マッパーはストレージからデータを回復し、マップされたオブジェクト (Plain-old オブジェクト) を作成します。マップされたオブジェクトは、別の場所に格納されていることをまったく知りません。

前述したように、TDG/RDG はリレーショナル テーブルとより内部的に関連しています。TDG オブジェクトは、テーブルの構造を表し、すべての一般的な操作を実装します。RGD オブジェクトには、テーブルの 1 つの行に関連するデータが含まれています。Data Mapper のマップされたオブジェクトとは異なり、RDG オブジェクトはコンテナー TDG を参照するため、全体の一部であるという意識があります。

于 2013-09-04T02:15:44.647 に答える