私はCodeIgniterを使いこなしており、初めてActive Recordsを訪れました。最初は、SQLを書く方法を本当に知らない人のために、それを却下しました。私の分析に欠陥があり、特にRailsでアクティブレコードがかなり顕著であることが分かりました。アクティブレコードの目的は何ですか？
しかし、アクティブレコードはどのような目的を持っていますか？異なるRDBMS個性から抽象化することですか？もしそうなら、私はそれがSQLの目的ではないと考えました。さらに、ベストプラクティスは何ですか？これらを使用する必要がありますか？事前に
おかげ
「Active Recordのパターンを」データ マッパーを使用するためにあなたを導くでしょう何 は、ほとんどのプログラミングフレームワークのコア部分になってきています。 CRUD（Create、Update、Read、Delete）タスクをより簡単に実現することができます。たとえば、多数のSQLを共通の単純なデータオブジェクトの挿入、更新、および削除に書き込む必要はなく、値をデータオブジェクトに割り当ててコマンドを実行するだけです。 $ object-> save（）を実行すると、SQLがコンパイルされて実行されます。
ほとんどのフレームワークでは、それぞれのアクティブレコードモデル内でデータ関係を実装しているため、オブジェクトに関連するデータへのアクセスを大幅に簡素化できます。たとえば、CodeIgniterでは、Categoryオブジェクトがデータベースからロードされた後、Category has many productsが指定された場合、単純なコード行でそのChild Productsをリストすることができます。
foreach ($category->products as $product) {
echo $product->name;
}
のActive Recordのもう一つの利点は、それが（長い間使用しているフレームワークが選択したデータベースのドライバを持っていると）異なるデータベースプラットフォームへのあなたのコードを簡単に移植可能ということ、あなたが言うように、であり、このもののあなたのアプリケーションが普及すれば、私は後で大きな価値を持ちます！
これは役に立ちましたでしょうか。 WikipediaはActive Recordをよく説明しており（http://en.wikipedia.org/wiki/Active_record_pattern）、CodeIgniterの文書も同様に扱われます。個人的に、私はCodeHgniterのPHP5のみのフォークであるKohanaPHP（http://www.kohanaphp.com）を使用しています。これはORMモデルが非常に便利であることがわかります！
アクティブレコードは、データアクセスのためのデザインパターンです...
現時点では私は、データアクセスに関する渡って来るように見える二つの主要なデザインパターンがあります。ActiveRecordのとリポジトリパターンは、
Active Recordは
あなたのオブジェクトには、DBにその状態を持続（またはその他の永続化メカニズム）のためのメソッドが含まれています
Customerオブジェクトがある可能性があります。
CustomerオブジェクトはCustomer.Save（）;, Customer.Get（int型ID）のような方法の束を有することになります。その他。
これらのメソッドは、本当に現実の世界での顧客とは何の関係もありません。これらは実際にアプリケーションのインフラストラクチャに関するものです。リポジトリパターンでは
リポジトリパターン
、顧客オブジェクトは、POCO、またはダム対象になります。あなたが顧客を保持したい場合にのみ、それは本当に顧客を表現するために必要メソッドとプロパティ（名前、メールアドレス、リストの受注などのようなもの）
を持っている - あなたは単にあなたのリポジトリに
を渡しますRepository.Save（MyCustomer）。
アクティブなレコードパターンはすばやく簡単に操作できます。残念ながら、お客様のドメインモデルは、お客様とはまったく関係のないこれらの方法で混乱します。これにより、時間の経過とともにドメインモデルを維持するのが少し難しくなります。アクティブレコードパターンを使用することは非常に適切であるような状況のロットの
。たとえば、おそらくあまり変わっていないかなりシンプルなアプリを書いているのなら、おそらくSubSonicを起動し、Active Record DALを生成するでしょう。私は20分以内に私のビジネスコードをコーディングして、すべてのDBのものはすでに世話をしています。
一方で、私は変更することが、高い感受性と、特に複雑なドメインをモデリングしています、私はむしろきれいな私のドメインモデルを維持し、NHibernateはまたは類似でリポジトリパターンを実装したい、なら...
ADO.Netを使用して自分自身のデータアクセスをロールバックして以来、ずっと長い時間がかかりました。
私はこのパターンについて私自身の見解を与えることができましたが、Active Record（および多くの他のもの）の最良の範囲は、Martin FowlerのPatterns of Enterprise Application Architectureです。チャプター10から
：
アクティブ・レコード
データベース表またはビューの行をラップするオブジェクト、 データベースアクセスをカプセル化し、そのデータにドメイン ロジックを追加します。
オブジェクトには、データと の両方の動作が含まれます。このデータの大部分は であり、 データベースに保存する必要があります。アクティブレコードでは、 という明白なアプローチが最も多く使用され、データアクセスはドメインオブジェクトの ロジックになります。このように すべての人々は、 のデータをデータベースとの間で読み書きする方法を知っています。
...それに
アクティブレコードを使用するための
も、このような、作成読み、 更新、削除など 複雑ではないドメインロジックのために良い 選択肢です。この構造では、単一のレコード で妥当性検査と の検証がうまく機能します。
...
Active Recordは単純化の主要 という利点があります。 アクティブレコードを作成するのは簡単ですが、わかりやすく です。彼らの主な の問題は、 アクティブレコードオブジェクトが データベーステーブルに直接対応する場合にのみ正常に機能するということです。 同型スキーマ。
ビジネス ロジックが複雑な場合、あなたはすぐに したいあなたのオブジェクトの直接 関係、コレクション、など 継承、およびを使用します。これらは をActive Recordに簡単にマッピングすることはできず、少しずつ追加する は非常に乱雑になります。代わりに
何かがあれば、クエリを簡単に書くことができます。私は、通常のMySQL構文が構文エラー（自分自身ではなく、自分自身である）とCIアクティブレコード構文であることがほとんどであることがわかります。これはまれに起こります。
アクティブレコードは、CI IMHO
+1の中でも最もクールな機能の1つです。非常に良い説明 –