activerecord をモデルとして使用しますが、これは良いアイデアですか?

Question

最近では Rails の人気のおかげで、多くの人がモデルとして activerecord を使い始めています。ただし、Rails について聞く前に (私の同僚グループはオープンソースのファンではなく、.NET スクールで教えられていました...)、最終学年のプロジェクトを行っているときに、モデルのこの定義を見つけました。

このモデルは、企業データと、このデータへのアクセスと更新を管理するビジネス ルールを表します。多くの場合、モデルは現実世界のプロセスに対するソフトウェア近似として機能するため、モデルを定義する際には単純な現実世界のモデリング手法が適用されます。

activerecord のようにモデルが 1 つのテーブルを表す必要があるとは言っていません。そして通常、トランザクション内では、いくつかの無関係なテーブルをクエリしてから、別のテーブルのデータを操作する必要がある場合があります...そのため、activerecord をモデルとして使用する場合、どちらかがすべてのロジック コードをコントローラー (一部の PHP フレームワークでよく使われている) に詰め込む必要があるため、データベース操作を実行するために activerecord モデルをテストしたりハッキングしたりすることが困難になります。マップ先のテーブルだけでなく、他の関連テーブルも同様に...

では、(私見ですが) activerecord を MVC アーキテクチャ パターンのモデルとして悪用することの何がそんなに素晴らしいのでしょうか?

Answer 1

Martin Fowler は、このパターンを他の 2 つのパターンまたはアーキテクチャとともに「エンタープライズ アプリケーション アーキテクチャのパターン」で説明しました。これらのパターンは、さまざまな状況や複雑さの度合いに適しています。

単純なことだけを行いたい場合は、トランザクションスクリプトを使用できます。これは、単一のスクリプトにビジネス ロジック、データ アクセス ロジック、プレゼンテーション ロジックが含まれている多くの古い ASP および PHP ページで見られたアーキテクチャです。物事がより複雑になると、これはすぐに崩壊します。

次にできることは、プレゼンテーションとモデルの間に分離を追加することです。これはアクティブレコードです。モデルは依然としてデータベースに関連付けられていますが、ビュー/ページなどの間でモデル/データアクセスを再利用できるため、柔軟性が少し高まります。柔軟性はそれほど高くありませんが、データ アクセス ソリューションによっては十分な柔軟性を備えています。.Net の CSLA などのフレームワークには、このパターンの多くの側面があります (Entity Framework もこれに少し似ていると思います)。保守不能になることなく、多くの複雑さを処理できます。

次のステップでは、データ アクセス レイヤーとモデルを分離します。これには通常、優れた OR マッパーか多大な作業が必要です。したがって、誰もがこの方法を望んでいるわけではありません。ドメイン駆動設計などの多くの方法論がこのアプローチを規定しています。

したがって、すべては文脈の問題です。何が必要で、何が最善の解決策なのか。私は今でも、単純な使い捨てコードにトランザクション スクリプトを使用することがあります。

Answer 2

ビジネス モデルとして Active Record (またはほぼ同じ ORM) を使用するのは得策ではないと何度も述べてきました。説明しましょう:

PHP がオープンソースで無料であるという事実 (そして長い話ですが...) により、フォーラム、GitHub などのサイト、Google コードなどにコードを注ぎ込む開発者の広大なコミュニティが PHP に提供されます。これは良いことだと思われるかもしれませんが、場合によっては「それほど良い」とは言えない場合があります。たとえば、あなたがプロジェクトに直面していて、その問題に対処するために PHP で書かれた ORM フレームワークを使用したいとします。たくさんあるでしょう 選択するオプション:

• 教義
• 推進、動かす
• Qコード
• 昏睡状態
• 小豆

そしてリストはまだまだ続きます。新しいプロジェクトが定期的に作成されます。そこで、本格的なフレームワークと、そのフレームワークに基づくソース コード ジェネレーターを構築したと想像してください。しかし、ビジネス クラスを配置しなかったのは、結局のところ、「なぜ同じクラスをもう一度書く必要があるのか​​?」という理由からです。時間が経ち、新しい ORM フレームワークがリリースされ、新しい ORM に切り替えたいと考えますが、データ モデルへの直接参照を使用して、ほぼすべてのクライアント アプリケーションを変更する必要があります。

要するに、Active Record と ORM はアプリケーションのデータ層に存在することを意図しており、これらをプレゼンテーション層と混在させると、今説明したこの例のような問題が発生する可能性があります。

@Mendelt の賢明な言葉を聞いてください。マーティン・ファウラーを読んでください。彼は OO デザインに関する多くの本や記事を出版し、このテーマに関する優れた資料を出版しています。また、調べてみるとよいかもしれません アンチパターン, 、より具体的には ベンダーロックイン, これは、アプリケーションをサードパーティのツールに依存させると起こることです。最後に書きました これ 同じ問題について話しているブログ投稿があるので、必要に応じてチェックしてください。

私の回答がお役に立てば幸いです。

Answer 3

Rails ActiveRecord を MVC のモデルとして使用することの優れた点は、自動 ORM (オブジェクト リレーショナル マッパー) が提供され、モデル間の関連付けを簡単に作成できることです。ご指摘のように、MVC が不足している場合があります。

したがって、多くのモデルが関与する複雑なトランザクションの場合は、コントローラーとモデルの間でプレゼンターを使用することをお勧めします (Rails プレゼンター パターン）。Presenter はモデルとトランザクション ロジックを集約し、簡単にテストできるようにします。すべてのビジネス ロジックをモデルまたはプレゼンター内に保持し、コントローラーの外に置くように努める必要があります (スキニーコントローラー、ファットモデル).