Rails 블로그와 책을 읽거나 컨퍼런스 강연을 보면 모델을 더 날씬하게 만드는 방법에 대해 많은 것을 배울 수 있습니다.
모델이 할 것이기 때문에 이러한 기술은 훌륭합니다. 처리하기에는 너무 크거나 복잡해집니다. 그러나 모델이 지속성, 연관 및 유효성 검사만 담당하도록 하고 싶습니까? 어쨌든 ActiveRecord 모델에 유지해야 하는 로직의 양은 어떻게 결정하나요?
스키니. 하지만 너무 마른 체형.
활성 레코드는 모델이 데이터베이스 스키마와 거의 일치할 때 가장 잘 작동하는 패턴입니다. 그것이 무엇을 위해 설계된 것입니다! 그런데 그게 무슨 뜻인가요?
-
일부 코드가 ActiveRecord 모델의 관점에서 작동한다면 모델에 들어갈 수 있습니다.
-
일부 코드가 여러 테이블/객체에 걸쳐 작동하고 명확한 소유자가 없으면 서비스 객체로 들어갈 수 있습니다.
-
속성과 유사한 모든 것(예:연결 또는 기타 속성에서 계산된 속성)은 ActiveRecord 모델에 포함되어야 합니다.
-
한 번에 여러 모델의 저장 또는 업데이트를 조정해야 하는 논리가 있는 경우 ActiveModel 양식 개체로 이동해야 합니다.
-
코드가 주로 뷰에서 모델을 표시하거나 형식을 지정하기 위한 것이라면 Rails 도우미 또는 Presenter로 이동해야 합니다.
이러한 지침 외에도 너무 커지는 클래스를 리팩토링하는 데 사용하는 것과 동일한 규칙을 사용해야 합니다. 그러나 일반적으로 일부 ActiveRecord 모델의 논리. 그들은 그것을 가지고 있습니다!
따라서 Rails는 Active Record 패턴을 선택했으므로 모델에 일부 논리가 있어야 합니다. 그런데 왜 Rails는 더 깔끔한 것 대신에 그 패턴을 선택했을까요?
루비는 무엇을 할까요?
엔터프라이즈 애플리케이션 아키텍처의 패턴에서 활성 레코드 패턴은 행 데이터 게이트웨이와 데이터 매퍼 사이의 중간 지점을 유지합니다. 행 데이터 게이트웨이 가능한 모든 모델 중 가장 마른 것처럼 테이블 행 주위에 대부분 멍청한 객체 지향 래퍼입니다. 데이터 매퍼 Active Records보다 복잡하고 비즈니스 로직만 포함하는 개체와 지속성 논리만 포함하는 개체 간에 변환하는 데 주로 사용됩니다.
따라서 Ruby의 맥락에서 Active Record가 절대적으로 올바른 기본 패턴입니다.
제가 왜 그런 말을 합니까?
Ruby는 프로그래머를 행복하게 하도록 설계되었습니다. 청결함과 편리함 사이에서 타협을 해야 할 때 거의 항상 편리함을 선택합니다.
내 말은, Array 공개 API에 100개 이상의 메서드가 있습니다. 톤이 있습니다. 서로의 별칭일 뿐입니다. 일부 개발자는 .detect 작성을 선호하기 때문에 .find .
그런 맥락에서 Rails는 더 유연하거나 객체 지향적인 순수성을 가진 패턴보다 편리한 패턴을 기본적으로 사용합니다. 루비 방식입니다. 그리고 저는 그것을 좋아합니다.
필요할 때 언제든지 더 유연한 것으로 리팩토링할 수 있습니다. 하지만 다시, YAGNI.