데이터 액세스 / 비즈니스 개체에 ActiveRecord 패턴을 사용하는 데 어떤 단점이 있는지 궁금합니다. 제가 머리 꼭대기에서 생각할 수있는 유일한 것은 그것이 단일 책임 원칙을 위반한다는 것입니다. 그러나 AR 패턴은이 이유만으로는 사용하지 않는 것을 정당화하기에 "충분히 좋은"것처럼 보이지 않을 정도로 일반적입니다. 보기는 다음과 코드 I 작업 종종 아무도 때문에 왜곡 될 수 있는 ) 고체 원칙을.
개인적으로 저는 ActiveRecord의 팬이 아닙니다 (AR이 "자연적"이라고 느끼는 Ruby on Rails 응용 프로그램을 제외하고는 클래스가 너무 많은 것처럼 느껴지고 데이터 액세스가 클래스 자체에 달려서는 안되기 때문에) 다루다. 비즈니스 오브젝트를 리턴하는 저장소를 사용하는 것을 선호합니다. 내가 사용하는 대부분의 코드는 다음과 같은 형태로 ActiveRecord 변형을 사용하는 경향이 있습니다 (이 방법이 부울 인 이유는 모르겠습니다).
public class Foo
{
// properties...
public Foo(int fooID)
{
this.fooID = fooID;
}
public bool Load()
{
// DB stuff here...
// map DataReader to properties...
bool returnCode = false;
if (dr.HasRows)
returnCode = true;
return returnCode;
}
}
또는 때때로 public static Foo FindFooByID(int fooID)파인더 를위한 방법과 public void Save()저장 / 업데이트 를 위한 방법을 갖는보다 "전통적인"방법 .
ActiveRecord는 일반적으로 구현하고 사용하기가 훨씬 간단하지만 복잡한 응용 프로그램 에는 너무 단순 해 보이지만 데이터 액세스 논리를 리포지토리에 캡슐화하여 더 강력한 아키텍처를 가질 수 있습니다 (스왑 아웃을 쉽게하는 것은 말할 것도 없습니다) 데이터 액세스 전략 (예 : Stored Procs + DataSets를 사용하고 LINQ 등으로 전환하려는 경우)
그렇다면 ActiveRecord가 작업에 가장 적합한 후보인지 결정할 때 고려해야 할 다른 패턴의 단점은 무엇입니까?