ActiveRecordモデルが太すぎるのはいつですか？

Active Recordは、モデルがデータベーススキーマと厳密に一致する場合に最適に機能するパターンです。それがそのために設計されたものです！ しかし、それはどういう意味ですか？

• 一部のコードがActiveRecordモデルの観点から機能する場合、そのコードはモデルに組み込まれる可能性があります。

• 複数のテーブル/オブジェクトにまたがるコードが機能し、実際には明確な所有者がいない場合、そのコードはサービスオブジェクトに入る可能性があります。

• 属性のようなもの（関連付けやその他の属性から計算された属性など）は、ActiveRecordモデルに入れる必要があります。

• 複数のモデルの保存または更新を一度に調整する必要があるロジックがある場合は、ActiveModelフォームオブジェクトに入れる必要があります。

• コードが主にビューでモデルを表示またはフォーマットすることを目的としている場合は、Railsヘルパーまたはプレゼンターに配置する必要があります。

これらのガイドラインを超えて、大きくなりすぎているクラスをリファクタリングするために使用するのと同じルールを使用する必要があります。ただし、一般的に、一部を残すことについて悪く感じることはありません。 ActiveRecordモデルのロジック。彼らはそれを持っていることを意図しています！

したがって、RailsはActive Recordパターンを選択したので、モデルにいくつかのロジックを含めることは理にかなっています。しかし、なぜRailsはよりクリーンなものではなくそのパターンを選んだのですか？

Rubyは何をしますか？

エンタープライズアプリケーションアーキテクチャのパターンでは、ActiveRecordパターンがRowDataGatewayとDataMapperの中間に位置します。 行データゲートウェイ は、可能なすべてのモデルの中で最も細いもののように、テーブル行の周りのほとんどダムオブジェクト指向のラッパーです。 データマッパー Active Recordsよりも複雑で、主にビジネスロジックのみを含むオブジェクトと永続ロジックのみを含むオブジェクト間の変換に使用されます。

したがって、Rubyのコンテキストでは、ActiveRecordは絶対に正しいデフォルトパターンです。

なぜ私はそれを言うのですか？

Rubyはプログラマーを幸せにするように設計されています。清潔さと利便性の間でトレードオフを強いられる場合、ほとんどの場合、利便性を選択します。

つまり、Array パブリックAPIには100を超えるメソッドがあります。 トンがあります 相互の単なるエイリアスであるメソッドの。一部の開発者は.detectを書くことを好むからです .findへ 。

その文脈では、Railsがデフォルトで、より柔軟なパターンよりも便利なパターン、またはよりオブジェクト指向の純度を持つパターンに設定されることは非常に理にかなっています。それはRubyのやり方です。そして、私はそれが大好きです。

必要なときに、いつでもより柔軟なものにリファクタリングできます。しかし、もう一度、YAGNI。