[ruby-on-rails] OO Design in Rails : 물건을 넣을 곳

Rails는 MVC 측면에서 구조를 제공하기 때문에 사용자에게 제공 되는 모델, 뷰 및 컨트롤러 컨테이너 만 사용하는 것이 당연 합니다. 초보자 (및 일부 중간 프로그래머)의 일반적인 관용구는 앱의 모든 논리를 모델 (데이터베이스 클래스), 컨트롤러 또는 뷰에 넣는 것입니다.

어느 시점에서 누군가 “지방 모델, 스키니 컨트롤러”패러다임을 지적하고, 중간 개발자는 서둘러 컨트롤러에서 모든 것을 소비하고이를 모델로 던져 애플리케이션 로직의 새로운 쓰레기통이되기 시작합니다.

실제로 스키니 컨트롤러는 좋은 생각이지만 모델에 모든 것을 넣는 추론은 실제로 최고의 계획은 아닙니다.

Ruby에는 모듈화를위한 몇 가지 좋은 옵션이 있습니다. 상당히 인기있는 대답은 lib메소드 그룹을 보유한 모듈 (보통 스태킹 )을 사용한 다음 해당 클래스에 모듈을 포함시키는 것입니다. 여러 클래스에서 재사용하려는 기능 범주가 있지만 기능이 클래스에 개념적으로 첨부되어있는 경우에 유용합니다.

모듈을 클래스에 포함 시키면 메소드는 클래스의 인스턴스 메소드가되므로 톤을 포함하는 클래스로 끝납니다. 방법을, 그들은 단지 여러 파일에 잘 정리하고 있습니다.

이 솔루션은 어떤 경우에는 잘 작동 할 수 있습니다. 다른 경우 에는 모델, 뷰 또는 컨트롤러 가 아닌 코드에서 클래스를 사용하는 것이 좋습니다.

그것에 대해 생각하는 좋은 방법은 “단일 책임 원칙”인데, 이는 클래스가 단일 (또는 소수) 사물을 책임 져야한다고 말합니다. 모델은 애플리케이션에서 데이터베이스로 데이터를 유지해야합니다. 컨트롤러는 요청을 받고 실행 가능한 응답을 반환 할 책임이 있습니다.

해당 상자에 잘 맞지 않는 개념 (지속성, 요청 / 응답 관리)이있는 경우 해당 아이디어를 어떻게 모델링 할 것인지 생각할 수 있습니다 . 비 모델링 클래스를 앱 / 클래스 또는 다른 곳에 저장하고 다음을 수행하여 해당 디렉토리를로드 경로에 추가 할 수 있습니다.

config.load_paths << File.join(Rails.root, "app", "classes")

승객 또는 JRuby를 사용하는 경우 열망하는로드 경로에 경로를 추가 할 수도 있습니다.

config.eager_load_paths << File.join(Rails.root, "app", "classes")

결론은 일단 Rails에서이 질문을하는 지점에 도달하면 Ruby chops을 강화하고 Rails가 기본적으로 제공하는 MVC 클래스가 아닌 모델링 클래스를 시작할 차례입니다.

업데이트 : 이 답변은 Rails 2.x 이상에 적용됩니다.

답변

# concerns/authentication.rb
module Authentication
  ...
end

# controllers/application_controller.rb
class ApplicationController
  include Authentication
end



# concerns/configurable.rb
module Configurable
  ...
end

class Model
  include Indexable
end

# controllers/foo_controller.rb
class FooController < ApplicationController
  include Indexable
end

# controllers/bar_controller.rb
class BarController < ApplicationController
  include Indexable
end

/lib/myapp.rb
module MyApp
  VERSION = ...
end

/lib/myapp/CacheKey.rb
/lib/myapp/somecustomlib.rb

/config/initializer/config.rb
/config/initializer/core_ext/string.rb
/config/initializer/core_ext/array.rb