activerecordをモデルとして、これは良い考えですか？

Question

最近、レールの人気のおかげで、多くの人がアクティブレコードをモデルとして使用し始めます。しかし、（私のピアグループはオープンソースのものではなく、私たちは.NETの学校で教えられました...）私が最後の1年間のプロジェクトを行っている間、私はこの定義をモデル

で見つけました

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

モデルはactiverecordと同じテーブルを表す必要はありません。通常、トランザクション内では、無関係のテーブルをいくつかクエリして、異なるテーブルのデータを操作する必要があります。つまり、activerecordがモデルとして使用されている場合は、いずれのロジックコードもコントローラに詰め込まなければなりませんいくつかのPHPフレームワークではちょっと普及している）、それがマッピングするテーブルだけでなく、他の関連するテーブルでもデータベース操作を実行するように、activerecordモデルをテストまたはハックすることが難しくなります...

MVCアーキテクチャーパターンのモデルとして（IMHO）activerecordを乱用するほど素晴らしいですか？

Answer 1

Martin Fowlerは、このパターンを企業アプリケーションアーキテクチャのパターンと、他の2つのパターンまたはアーキテクチャと共に説明しました。これらのパターンは、さまざまな状況や複雑さの異なる量に適しています。

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

次は、プレゼンテーションとモデルの間にいくつかの分離を加えることです。これはアクティブレコードです。モデルは依然としてデータベースに結びついていますが、ビュー/ページ/その他の間でモデル/データアクセスを再利用できるため、柔軟性はもう少しあります。それは可能な限り柔軟ではありませんが、データアクセスソリューションによっては柔軟性があります。 .NETのCSLAのようなフレームワークは、このパターンから多くの側面を持っています（Entity Frameworkはこれもあまりにも似ているようです）。維持不能にならずに、まだ複雑さを多く処理することができます。

次のステップでは、データアクセスレイヤーとモデルを分離します。これには、通常、ORマッパーや多くの作業が必要です。だから誰もがこのように行きたくはない。ドメイン駆動設計のような方法論のロットは、このアプローチを支持している。

これはすべての文脈の問題です。何が必要なのか、最良の解決策は何か。私はまだ単純なシングルユースコードのためにトランザクションスクリプトを使用しています。

Answer 2

MVCのモデルとしてRails ActiveRecordを使用することの素晴らしい点は、自動ORM（Object Relational Mapper）を提供し、モデル間の関連付けを簡単に作成できることです。あなたが指摘したように、MVCは時々欠けていることがあります。

したがって、多くのモデルを含む複雑なトランザクションでは、コントローラとモデルの間にプレゼンターを使用することをお勧めします（Rails Presenter Pattern）。プレゼンターはモデルとトランザクションロジックを集約し、容易にテスト可能なままになります。モデルやプレゼンター、コントローラーのビジネスロジックをすべて維持するように努力したいと思っています（Skinny Controller, Fat Model）。

Answer 3

ビジネスモデルと同じアクティブレコード（またはほぼ同じORM）を使用することは良い考えではないと何度も言いました。

PHPがオープンソースであるという事実（そしてその長い話など）は、フォーラム、GitHub、Googleコードなどのサイトにコードを流す広大な開発者コミュニティを提供しています。あなたはこれを良いものと見なすかもしれませんが、時には "とても良い"ものではありません。たとえば、あなたがプロジェクトに直面していると、あなたはPHPで書かれたあなたの問題に直面ためのORMフレームワークを使用したい、うまく...あなたはoptions to choose forがたくさんあるだろうとします

• 教義
• Propelの
• QCodo
• 鈍感
• RedBean

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

ボトムライン、アクティブレコードとORMはアプリケーションのデータレイヤーにあることを前提としていますので、プレゼンテーションレイヤーと混在させると、ちょうどこの例のような問題が発生します。

Hear @ Mendeltの賢明な言葉：Martin Fowlerを読む。 OOデザインに関する多くの書籍や記事を掲載し、その上にいくつかの良い資料を掲載しています。また、Anti-Patterns、具体的にはVendor Lock Inを調べることもできます。これは、アプリケーションをサードパーティのツールに依存させる場合に起こります。最後に、私はthisのブログ投稿に同じ問題について話しました。あなたがしたいのなら、それをチェックしてください。

私の答えはどんな用途のものでもあります。