Data Mapper가 Active Record보다 더 현대적인 추세입니까?

Data Mapper가 Active Record보다 더 현대적인 추세입니까?

최근에 구현을 Active Record에서 Data Mapper로 전환할 계획이라고 발표한 ORM을 몇 개 접했습니다.이 주제에 대한 제 지식은 매우 제한적입니다.그렇다면 Data Mapper가 Active Record보다 더 최신 데이터인지에 대해 잘 아는 사람들에게 질문을 던집니다.액티브 레코드(Active Record) 운동이 시작될 무렵이었습니까?그 둘은 어떤 관계입니까?

마지막으로, 저는 데이터베이스 담당자가 아니고 이 주제에 대해 거의 알지 못하기 때문에, (데이터 담당자가 아닌) 소프트웨어를 작성하는 사람으로서 데이터 맵퍼 구현으로 이동하는 ORM을 따라야 합니까?

DataMapper는 더 최신의 것이 아니라 ORM에 더 적합합니다.

사람들이 변화하는 주된 이유는 ActiveRecord가 좋은 ORM을 만들지 못하기 때문입니다.AR은 데이터베이스 테이블 또는 뷰에 행을 래핑하고 데이터베이스 액세스를 캡슐화한 다음 해당 데이터에 도메인 로직을 추가합니다.따라서 정의상 AR은 데이터베이스 레코드를 1:1로 표현한 것이므로 단순한 CRUD에 특히 적합합니다.

일부 AR은 관련 데이터를 불러오는 기능을 추가하여 사람들이 AR을 ORM이라고 믿게 만들었습니다.그것은 아니다.ORM의 목적은 데이터베이스 구조와 도메인 개체 간의 개체 관계 임피던스 불일치를 해결하는 것입니다.AR을 사용할 경우, 적절한 OO 설계가 아닌 데이터베이스 행을 나타내기 때문에 이러한 임피던스 불일치를 해결하지 못합니다.DB 레이아웃을 개체에 연결하고 있습니다.객체 관계적 행동 패턴 중 일부는 여전히 적용될 수 있습니다(예: 게으른 로딩).

AR이 종종 비판을 받는 또 다른 이유는 비즈니스 로직과 DB 액세스 로직이라는 두 가지 우려가 섞여 있기 때문입니다.이로 인해 원치 않는 결합이 발생하고 대규모 응용프로그램에서 유지보수성과 유연성이 떨어질 수 있습니다.두 레이어 사이에는 분리가 없습니다.결합하면 항상 유연성이 떨어집니다.

반면, DataMapper는 객체와 데이터베이스 간에 데이터를 이동하면서 데이터를 서로 독립적으로 유지하고 맵퍼 자체를 유지합니다.구현하기는 더 어렵지만 응용프로그램에서 훨씬 더 유연한 설계를 가능하게 합니다.도메인 개체가 더 이상 db 구조와 일치할 필요가 없습니다.DAL과 도메인 계층은 분리됩니다.

게시물이 8년이 되었음에도 2018년에도 문제는 여전히 유효합니다.

활동 기록은 안티패턴입니다. 조심하세요.코드와 데이터베이스 간의 매우 긴밀한 결합을 만들어냅니다.소규모 단순 프로젝트의 경우에는 문제가 되지 않을 수 있습니다.하지만 더 큰 곳에서는 사용하지 말 것을 강력히 권합니다.

좋은 OOP 디자인은 층층이 쌓입니다.입력 계층, 서비스 계층, 저장소 계층, 데이터 맵퍼 및 DB - 단순한 예입니다.입력 계층과 DB를 혼용해서는 안됩니다.어떻게 할 수 있죠?예를 들어 Laravel에서는 다음과 같은 Validator 규칙을 사용할 수 있습니다.

'email' => 'exists:staff,email'

테이블 직원에게 이메일이 존재하는지 확인합니다.이것은 완전한 OOP 넌센스입니다.DB 열 이름으로 최상위 계층을 조입니다.나는 나쁜 OOP 디자인의 더 좋은 예를 상상할 수 없습니다.

결론: 블로그와 같이 2-3개의 테이블로 구성된 간단한 사이트를 작성하는 경우 활성화된 기록은 문제가 되지 않을 수 있습니다.더 큰 것은 Data Mapper를 선택하고 IoC, SoC 등과 같은 OOP 원칙에 주의해야 합니다.

언급URL : https://stackoverflow.com/questions/3828265/is-data-mapper-a-more-modern-trend-than-active-record