activerecord를 모델로 사용하는 것이 좋습니다.

Question

레일스의 인기 덕분에 많은 사람들이 activerecord를 모델로 사용하기 시작했습니다. 그러나 필자가 레일스에 대해 듣기도 전에 (필자의 동료 그룹은 오픈 소스에 대한 팬이 아니었다. 우리는 .NET 학교에서 가르쳤다 ...) 그리고 마지막 해의 프로젝트에서 나는이 정의를 모델

에서 발견했다.

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

모델이 하나의 테이블을 activerecord의 기능으로 나타내야한다고 말하지 않습니다. 일반적으로 트랜잭션 내에서 관련없는 테이블을 쿼리 한 다음 다른 테이블의 데이터를 조작해야 할 수도 있습니다. 따라서 activerecord가 모델로 사용되면 컨트롤러 중 하나에 모든 논리 코드를 넣어야합니다. 일종의 PHP 프레임 워크에서 인기가있다.) 테스트하거나 해킹하여 activerecord 모델을 매핑하는 테이블뿐만 아니라 다른 관련 테이블에서도 데이터베이스 작업을 수행 할 수있다.

MVC 아키텍처 패턴에서 모델로서의 (IMHO) activerecord를 악용하는 것에 대해 대단한가요?

Answer 1

마틴 파울러 (Martin Fowler)는이 패턴을 다른 두 가지 패턴 또는 아키텍처와 함께 엔터프라이즈 애플리케이션 아키텍처 패턴에 설명했습니다. 이러한 패턴은 상황에 따라 다르며 복잡성도 다릅니다.

간단한 물건 만 원하는 경우 트랜잭션 스크립트를 사용할 수 있습니다. 이것은 하나의 스크립트에 비즈니스 로직, 데이터 액세스 로직 및 프리젠 테이션 로직이 포함 된 많은 ASP 및 PHP 페이지에서 본 아키텍처입니다. 상황이 더욱 복잡해지면이 부분이 빠르게 떨어져 버립니다.

다음으로 할 수있는 일은 프레젠테이션과 모델간에 약간의 차이점을 추가하는 것입니다. 이것은 액티브 레코드입니다. 모델은 여전히 ​​데이터베이스에 묶여 있지만보기/페이지/기타간에 모델/데이터 액세스를 다시 사용할 수 있기 때문에 유연성이 조금 더 높아졌습니다. 유연하지는 않지만 데이터 액세스 솔루션에 따라 유연성이 충분합니다. .NET에서 CSLA와 같은 프레임 워크는이 패턴에서 많은 측면을 가지고 있습니다 (Entity Framework가 너무 많이 보입니다). 유지 보수가 불가능하지 않고도 여전히 많은 복잡성을 처리 할 수 ​​있습니다.

다음 단계는 데이터 액세스 레이어와 모델을 분리하는 것입니다. 이것은 대개 좋은 OR 매퍼 또는 많은 작업이 필요합니다. 그래서 모두가 이런 식으로 가고 싶어하지는 않습니다. 도메인 기반 디자인과 같은 방법론의 많은 방법이 이러한 접근 방식을 옹호합니다.

모든 상황이 그렇습니다. 무엇이 필요하며 가장 좋은 해결책은 무엇입니까? 나는 여전히 간단한 단일 사용 코드를 위해 때때로 트랜잭션 스크립트를 사용한다.

Answer 2

레일스 ActiveRecord를 MVC에서 모델로 사용하는 것이 가장 좋은 점은 자동 ORM (Object Relational Mapper)과 모델 간의 연관성을 쉽게 만들 수 있다는 것입니다. 앞서 지적한 것처럼 MVC는 때때로 부족할 수 있습니다.

따라서 많은 모델이 포함 된 복잡한 트랜잭션의 경우 컨트롤러와 모델 (Rails Presenter Pattern) 사이에 발표자를 사용하는 것이 좋습니다. Presenter는 모델과 트랜잭션 논리를 집계하고 쉽게 테스트 할 수 있습니다. 모델이나 발표자, 그리고 컨트롤러 (Skinny Controller, Fat Model)에서 모든 비즈니스 로직을 유지하려고 노력하고 싶습니다.

Answer 3

비즈니스 모델과 같이 액티브 레코드 (또는 거의 동일한 ORM)를 사용하는 것이 좋은 생각이 아닙니다. 설명해 드리겠습니다 :

사실 PHP는 오픈 소스이며 Free (그리고 그 모든 긴 이야기 ...) 포럼, GitHub, Google 코드와 같은 사이트에 코드를 쏟아내는 방대한 개발자 커뮤니티를 제공합니다. 이것을 좋은 것으로 볼 수도 있지만 때로는 "너무 좋아"않는 경향이 있습니다.

• 교리
• 추진
: 예를 들어, 프로젝트에 직면하고 있다고 가정하고 PHP로 작성된 문제에 직면위한 ORM 프레임 워크를 사용하려면, 음 ... 당신은 options to choose for를 많이해야합니다
• QCodo
• 무기력
• RedBean

그리고 목록 및갑니다. 새로운 프로젝트가 정기적으로 만들어집니다. 따라서 프레임 워크를 기반으로 완전한 프레임 워크와 소스 코드 생성기를 구축했다고 상상해보십시오. 하지만 결국 비즈니스 수업을 배정하지 않았습니다. 이유는 결국 "같은 수업을 다시 쓰는 이유는 무엇입니까?"때문입니다. 시간이 갈수록 새로운 ORM 프레임 워크가 릴리스되고 새로운 ORM으로 전환하려고하지만 데이터 모델을 직접 참조하여 거의 모든 클라이언트 응용 프로그램을 수정해야합니다.

하단의 액티브 레코드와 ORM은 애플리케이션의 데이터 레이어에 있어야합니다. 프레젠테이션 레이어와 믹스하면 방금 놓은 예제와 같은 문제가 발생할 수 있습니다.

Hear @ Mendelt의 현명한 말 : Martin Fowler를 읽으십시오. OO 디자인에 많은 책과 기사를 집어 넣었고 그 주제에 대한 좋은 자료를 발표했습니다. 또한 Anti-Patterns을보다 구체적으로 Vendor Lock In으로 조사하는 것이 좋습니다. 이는 타사 도구에 의존하는 응용 프로그램을 만들 때 발생합니다. 마지막으로, 나는 동일한 게시물에 대해 this 블로그 게시물을 작성 했으므로 원하는 경우 체크 아웃하십시오.

희망은 내 대답은 어떤 용도로 사용되었습니다.