7

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

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

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

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

4

3 に答える 3

8

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

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

次にできることは、プレゼンテーションとモデルを分離することです。アクティブレコードです。モデルは引き続きデータベースに関連付けられていますが、ビュー/ページ/その他の間でモデル/dataccess を再利用できるため、柔軟性が少し向上します。可能な限り柔軟ではありませんが、データ アクセス ソリューションによっては十分に柔軟に対応できます。.Net の CSLA のようなフレームワークには、このパターンから多くの側面があります (Entity Framework もこれに少し似すぎていると思います)。メンテナンスが困難になることなく、多くの複雑さを処理できます。

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

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

于 2008-09-11T13:50:52.810 に答える
2

ビジネスモデルとして Active Record (またはほぼ同じ ORM) を使用するのは得策ではないと何度も言いました。説明させてください：

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

  • 教義
  • 推進、動かす
  • QCodo
  • 休眠
  • 小豆

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

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

@Mendelt の賢明な言葉を聞いてください。Martin Fowler を読んでください。彼は OO 設計に関する多くの書籍や記事を執筆しており、このテーマに関する優れた資料をいくつか公開しています。また、 Anti-Patterns、より具体的にはVendor Lock Inを調べることもできます。これは、アプリケーションをサードパーティ ツールに依存させるときに発生することです。最後に、同じ問題について話しているこのブログ投稿を書いたので、必要に応じてチェックしてください。

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

于 2010-11-24T03:00:01.270 に答える
1

Rails ActiveRecord を MVC のモデルとして使用することの優れた点は、自動 ORM (Object Relational Mapper) が提供され、モデル間の関連付けを簡単に作成できることです。ご指摘のとおり、MVC が不足している場合があります。

したがって、多くのモデルが関係する複雑なトランザクションの場合は、コントローラーとモデルの間でプレゼンターを使用することをお勧めします ( Rails Presenter Pattern )。プレゼンターは、モデルとトランザクション ロジックを集約し、簡単にテストできる状態を維持します。すべてのビジネス ロジックをモデルまたはプレゼンターに保持し、コントローラー ( Skinny Controller、Fat Model )から除外するように努力することは間違いありません。

于 2008-09-11T14:09:08.947 に答える