모든 데이터 액세스에 저장 프로 시저 만 사용하는 회사에서 일하므로 로컬 데이터베이스를 동기화하여 새 프로세스를 실행해야 할 때마다 데이터베이스를 동기화하는 것이 매우 성가신 일입니다. 과거에는 몇 가지 기본 ORM을 사용해 왔으며 경험이 훨씬 좋고 깨끗합니다. 개발 관리자와 팀원들에게 향후 개발을 위해 어떤 종류의 ORM을 사용할 것을 제안하고 싶습니다. 팀의 나머지 팀은 저장 프로 시저에만 익숙하고 다른 것을 사용한 적이 없습니다. 현재 아키텍처는 .NET 1.1과 같이 작성된 .NET 3.5이며, 이상한 GodRecord 구현을 사용하고 코드 숨김 파일에서 반복되는 형식화되지 않은 DataSet을 반환하는 "신 클래스"와 함께 .NET 3.5입니다. 클래스는 다음과 같이 작동합니다.
class Foo {
public bool LoadFoo() {
bool blnResult = false;
if (this.FooID == 0) {
throw new Exception("FooID must be set before calling this method.");
}
DataSet ds = // ... call to Sproc
if (ds.Tables[0].Rows.Count > 0) {
foo.FooName = ds.Tables[0].Rows[0]["FooName"].ToString();
// other properties set
blnResult = true;
}
return blnResult;
}
}
// Consumer
Foo foo = new Foo();
foo.FooID = 1234;
foo.LoadFoo();
// do stuff with foo...디자인 패턴은 거의 적용되지 않습니다. 테스트는 전혀 없습니다 (아무도 단위 테스트를 작성하는 방법을 모르며 테스트는 웹 사이트를 수동으로로드하고 파킹하여 수행합니다). 데이터베이스를 살펴보면 199 개의 테이블, 13 개의 뷰, 926 개의 저장 프로 시저 및 93 개의 함수가 있습니다. 배치 작업 또는 외부 작업에 약 30여 개의 테이블이 사용되고 나머지는 핵심 응용 프로그램에 사용됩니다.
이 시나리오에서 다른 접근법을 추구 할 가치가 있습니까? "작동하는"이후 기존 코드를 리팩터링 할 수 없으므로 ORM을 사용하도록 기존 클래스를 변경할 수 없지만 새 모듈을 얼마나 자주 추가하는지는 잘 모르겠습니다. ORM이 올바른 접근 방식인지 (저장 프로 시저 및 데이터 세트에 너무 많이 투자했는지) 확실하지 않습니다. 그것이 올바른 선택이라면, 그것을 사용하는 경우를 어떻게 제시해야합니까? 내 머리 꼭대기에서 내가 생각할 수있는 유일한 이점은 코드가 깨끗하다는 것입니다 (현재 아키텍처가 ' ORM을 염두에두고 기본적으로 미래 모듈에 ORM을 배심원으로 배치 할 것이지만 오래된 모듈은 여전히 DataSets를 사용하고 있습니다) 등등이지만 그게 전부이고, 나는 논쟁이 얼마나 설득력이 있는지 모르겠습니다. 유지 보수성은 또 다른 관심사이지만 나 외에는 아무도 염려하지 않는 것입니다.