2

私は現在、ActiveRecord を ORM として、sqlite をデータベースとして使用する Ruby (Rails ではない) でアプリケーションを構築しています。

私の質問を明確にするためのサンプルコード：

class User < ActiveRecord::Base
  has_many :logins, :foreign_key => :user_id
  has_many :categories, :foreign_key => :user_id
  has_many :news, :foreign_key => :user_id
  has_many :settings, :foreign_key => :user_id

  class << self
    def get_user_by_id(id)
      find(id)
    end

    def insert(username, password)
      create(:username => username, :password => password)
    end
  end
end

コード (関係、モデルなど) は今のところまったく複雑ではありません。ただし、モデルが大きくなり始めると、ビジネス ロジックと永続化ロジックを同じクラスに混在させたくありません。永続化方法 (ファイル、メモリ内、その他のデータベース orm) を変更できるようにしたいと考えています。これに対する確立された方法はありますか？Rails では「細いコントローラ、太いモデル」が一般的であると読みましたが、これを回避する方法を探しています。

4

1 に答える 1

1

残念ながら、ActiveRecordパターンは状況に最適なソリューションではない可能性があります。ActiveRecordパターンの定義は次のとおりです。

オブジェクトはデータと動作の両方を伝達します。このデータの多くは永続的であり、データベースに保存する必要があります。Active Recordは最も明白なアプローチを使用し、ドメインオブジェクトにデータアクセスロジックを配置します。このようにして、すべての人がデータベースとの間でデータを読み書きする方法を知っています。

おそらく、ビジネスロジックと永続性を分離するために特別に設計されたデータマッパーパターン（およびデータマッパーORM ）を調べたいと思うかもしれません。

そうは言っても、もしあなたが本当にActiveRecordを使わなければならないのなら、私は次のようなコンポジションを投入するでしょう：

class UserRepository < ActiveRecord::Base
  # all the persistence stuff goes in here
end

class User
  def initialize(login, repository=UserRepository)
    @repository = repository
    @user = @repository.find_by_login(login)
  end

  def instanography
    #complicated business logic
  end

  def method_missing(m, *args, &block)
    @user.send(m, *args, &block)
  end
end

上記の例で示したように、Userオブジェクトを実際のアクティブなレコードオブジェクトのプロキシとして機能させ、すべてのビジネスロジックを保持し、永続性を隠します。

于 2013-02-19T18:01:31.360 に答える