activerecord를 모델로 삼는 게 좋은 생각인가요?

Question

최근 Rails의 인기에 힘입어 많은 사람들이 ActiveRecord를 모델로 삼기 시작했습니다.그러나 Rails에 대해 듣기 전에(나의 동료 그룹은 오픈 소스 팬이 아니었고 우리는 .NET 학교에서 가르쳤습니다...) 마지막 해 프로젝트를 수행하는 동안 모델에 대한 이 정의를 찾았습니다.

모델은 엔터프라이즈 데이터와 이 데이터에 대한 액세스 및 업데이트를 관리하는 비즈니스 규칙을 나타냅니다.종종 모델은 실제 프로세스에 대한 소프트웨어 근사치로 사용되므로 모델을 정의할 때 간단한 실제 모델링 기술이 적용됩니다.

모델이 activerecord가 수행하는 것처럼 하나의 테이블을 나타내야 한다고 말하는 것은 아닙니다.그리고 일반적으로 트랜잭션 내에서 관련되지 않은 몇 개의 테이블을 쿼리한 다음 다른 테이블의 데이터를 조작해야 할 수도 있습니다.따라서 activerecord가 모델로 사용되는 경우 모든 논리 코드를 컨트롤러(일부 PHP 프레임워크에서 다소 인기 있음)에 밀어 넣어야 하므로 Activerecord 모델을 테스트하거나 해킹하여 데이터베이스 작업을 수행하기가 어렵습니다. 매핑되는 테이블뿐만 아니라 다른 관련 테이블도 마찬가지입니다.

그렇다면 MVC 아키텍처 패턴의 모델로 (IMHO) ActiveRecord를 남용하는 것의 장점은 무엇입니까?

Answer 1

Martin Fowler는 두 가지 다른 패턴 또는 아키텍처와 함께 엔터프라이즈 애플리케이션 아키텍처 패턴에서 이 패턴을 설명했습니다.이러한 패턴은 다양한 상황과 다양한 복잡성에 적합합니다.

간단한 것만 원할 경우 트랜잭션 스크립트를 사용할 수 있습니다.이는 단일 스크립트에 비즈니스 논리, 데이터 액세스 논리 및 프리젠테이션 논리가 포함되어 있는 많은 기존 ASP 및 PHP 페이지에서 본 아키텍처입니다.상황이 더 복잡해지면 이것은 빠르게 무너집니다.

다음으로 할 수 있는 일은 프리젠테이션과 모델 사이에 약간의 분리를 추가하는 것입니다.액티브레코드 입니다.모델은 여전히 ​​데이터베이스에 연결되어 있지만 보기/페이지/무엇이든 간에 모델/데이터 액세스를 재사용할 수 있으므로 유연성이 좀 더 높아집니다.가능한 만큼 유연하지는 않지만 데이터 액세스 솔루션에 따라 충분히 유연할 수 있습니다..Net의 CSLA와 같은 프레임워크는 이 패턴의 많은 측면을 가지고 있습니다(Entity Framework도 이와 너무 비슷해 보인다고 생각합니다).유지 관리가 불가능해지지 않으면서도 많은 복잡성을 처리할 수 있습니다.

다음 단계는 데이터 액세스 계층과 모델을 분리하는 것입니다.이를 위해서는 일반적으로 좋은 OR 매퍼 또는 많은 작업이 필요합니다.그러니 모두가 이 길로 가고 싶어하는 것은 아닙니다.도메인 중심 설계와 같은 많은 방법론이 이 접근 방식을 설명합니다.

따라서 그것은 모두 상황의 문제입니다.무엇이 필요하며 최상의 솔루션은 무엇입니까?나는 아직도 가끔 간단한 일회용 코드를 위해 트랜잭션 스크립트를 사용합니다.

Answer 2

나는 Active Record(또는 거의 동일한 ORM)를 비즈니스 모델로 사용하는 것은 좋은 생각이 아니라고 여러 번 말했습니다.설명하겠습니다.

PHP가 오픈 소스, 무료(그리고 그 모든 긴 이야기...)라는 사실은 포럼, GitHub, Google 코드 등과 같은 사이트에 코드를 쏟아 붓는 광범위한 개발자 커뮤니티를 제공합니다.이것을 좋은 것으로 볼 수도 있지만 때로는 "그렇게 좋지" 않은 경향이 있습니다.예를 들어, 프로젝트를 진행 중이고 PHP로 작성된 문제를 해결하기 위해 ORM 프레임워크를 사용하고 싶다고 가정해 보겠습니다.당신은 많이 가질 것입니다 선택할 수 있는 옵션:

• 교의
• 추진
• 큐코도
• 무기력
• 레드빈

그리고 목록은 계속됩니다.새로운 프로젝트가 정기적으로 생성됩니다.따라서 완전한 프레임워크와 해당 프레임워크를 기반으로 하는 소스 코드 생성기를 구축했다고 상상해 보십시오.하지만 결국 "왜 같은 클래스를 다시 작성하는가?"라는 이유로 비즈니스 클래스를 배치하지 않았습니다.시간이 흘러 새로운 ORM 프레임워크가 출시되어 새로운 ORM으로 전환하고 싶지만 데이터 모델에 대한 직접 참조를 사용하여 거의 모든 클라이언트 애플리케이션을 수정해야 합니다.

결론적으로 Active Record 및 ORM은 애플리케이션의 데이터 계층에 있어야 합니다. 이를 프레젠테이션 계층과 혼합하면 방금 설명한 이 예와 같은 문제가 발생할 수 있습니다.

@Mendelt의 현명한 말을 들어보세요:마틴 파울러를 읽어보세요.그는 OO 디자인에 관한 많은 책과 기사를 냈으며 해당 주제에 대한 좋은 자료도 출판했습니다.또한 다음을 살펴보고 싶을 수도 있습니다. 안티 패턴, 더 구체적으로 공급업체 잠금, 이는 애플리케이션을 타사 도구에 종속되게 만들 때 발생하는 일입니다.마지막으로 나는 썼다. 이것 동일한 문제에 대해 설명하는 블로그 게시물이므로 원하는 경우 확인해 보세요.

제 답변이 도움이 되었기를 바랍니다.

Answer 3

MVC에서 Rails ActiveRecord를 모델로 사용할 때 가장 좋은 점은 자동 ORM(객체 관계형 매퍼)을 제공하고 모델 간 연결을 쉽게 생성할 수 있다는 것입니다.지적했듯이 MVC는 때때로 부족할 수 있습니다.

따라서 많은 모델이 관련된 복잡한 트랜잭션의 경우 컨트롤러와 모델 사이에 프레젠터를 사용하는 것이 좋습니다(레일즈 프리젠터 패턴).Presenter는 모델과 트랜잭션 논리를 집계하고 쉽게 테스트할 수 있습니다.당신은 모든 비즈니스 로직을 모델이나 프리젠터에 유지하고 컨트롤러 외부에 유지하기 위해 노력하고 싶을 것입니다(마른 컨트롤러, 뚱뚱한 모델).