Railsでモデルがビジネスロジックと永続性の両方に使用されるという考えは好きではありません。2つを分離したいと思います。モデルにビジネスロジックを含め、別のクラス階層を使用して永続化します。
誰かがこれを試し、牽引力を得たことがありますか?頭のてっぺんから、Railsに強く反しているようです。form_forは、ビジネスオブジェクトで直接機能する多くの一般的なプラグインと同様に、ActiveModelオブジェクトが機能する必要があります。
何かご意見は?
Railsでモデルがビジネスロジックと永続性の両方に使用されるという考えは好きではありません。2つを分離したいと思います。モデルにビジネスロジックを含め、別のクラス階層を使用して永続化します。
誰かがこれを試し、牽引力を得たことがありますか?頭のてっぺんから、Railsに強く反しているようです。form_forは、ビジネスオブジェクトで直接機能する多くの一般的なプラグインと同様に、ActiveModelオブジェクトが機能する必要があります。
何かご意見は?
あなたが述べたとおりにそれを行うのは難しい/面倒だと思いますが、コードを分離する良い方法がいくつかあります.
それを行う1つの方法は、あなたが言ったように、永続化用とビジネスロジック用の2つの別々のクラスを持つことです。それらを Foo と FooBL と呼びましょう。Foo は ActiveRecord から継承し、検証ロジックと、データのクエリと操作のためのいくつかの簡単なメソッドを含みます。FooBL は、必要に応じて Foo クラスを使用する通常の ruby クラスになります。Ruby のDelegation機能の一部を使用して、Foo の属性とメソッドの一部を直接使用することもできます。
もう 1 つの少し異なる方法は、Draper gem のようにプレゼンターを使用することです。永続化ロジックからビジネス ロジックを分離するのではなく、ビュー関連のロジックを分離します。探しているものとは正確には異なりますが、コードのクリーンアップには役立ちます。
また、Avdi Grimm の本Object on Railsもご覧になることをお勧めします。彼は、これらのパターンとプラクティスのいくつかを深く見ていきます。
幸運を!