자신의 데이터 액세스 / 데이터 매핑 계층을 작성하는 것이 "좋은"아이디어입니까?

우리는 현재 즉시 사용 가능한 객체 관계형 매퍼를 사용하거나 우리 자신의 롤링을 선택할 수있는 상황에 처해 있습니다.

데이터 계층과 비즈니스 계층이 불행하게 뭉친 레거시 응용 프로그램 (ASP.NET + SQL Server)이 있습니다. 시스템은 데이터 액세스 측면에서 특히 복잡하지 않습니다. 상호 관련된 테이블의 큰 그룹 (35-40)에서 데이터를 읽고 메모리에서 조작하고 요약 형식으로 다른 테이블에 다시 저장합니다. 이제 일부 리팩토링 기회가 있으며 데이터 액세스를 분리하고 올바르게 구성하는 데 사용할 후보 기술을 찾고 있습니다.

우리가 결정한 기술은 다음과 같습니다.

• 도메인 모델에 POCO 객체가 있으며 지속성
• 추상화 된 기본 데이터 소스에 대해 도메인 모델 객체를 단위 테스트 할 수있는 추상화 계층

이미 패턴 및 프레임 워크 등의 측면에서 이미 많은 것들이 있습니다.

개인적으로 저는 ADO.NET Unit Testable Repository Generator / POCO Entity Generator 와 함께 EF를 사용하려고 합니다. 모든 요구 사항을 충족하고 Repo / UnitOfWork 패턴에 쉽게 번들로 묶을 수 있으며 DB 구조는 합리적으로 성숙하여 이미 리팩터링을 거쳐 모델을 매일 변경하지 않습니다.

그러나 그룹의 다른 사람들은 우리 자신의 DAL을 처음부터 완전히 설계 / 롤링하도록 제안하고 있습니다. (사용자 정의 DataMappers, DataContexts, Repository, 모든 곳의 인터페이스, 콘크리트 객체를 생성하기위한 의존성 주입 과잉, 사용자 정의 LINQ- 언더 리 쿼리 변환, 사용자 정의 캐싱 구현, 사용자 정의 FetchPlan 구현 ...) 목록은 계속되고 솔직합니다. 광기로

"적어도 우리는 우리 자신의 코드를 제어 할 것입니다"또는 "이전 프로젝트에서 L2S / EF를 사용해 보았지만 두통에 지나지 않았습니다." (내가 프로덕션 환경에서 두 가지를 모두 사용했지만 문제가 거의없고 관리가 용이 ​​한 것을 발견했지만)

따라서 경험 많은 숙련 된 개발자 / 건축가에게이 제품을 완전히 재난이 될 것 같은 것으로부터 멀리 떨어 뜨리는 데 도움이되는 지혜로운 말이 있습니다. 나는 EF 문제를 피 함으로써 얻은 이익 이 바퀴를 다시 발명하려고 시도하는 것만 큼 빨리 사라질 것이라고 생각합니다 .

기존 ORM에 대한 두 가지 인수가 모두 유효하지 않습니다.

"적어도 우리는 우리 자신의 코드를 통제 할 것입니다"

자신의 언어를 쓰지 않겠습니까? 자신의 프레임 워크? 자신의 운영 체제? 또한 모든 것을 제어 할 수 있도록 자신 만의 하드웨어를 만드는 것이 좋습니다.

"오, 나는 이전 프로젝트에서 L2S / EF를 사용해 왔는데 그것은 두통 일뿐입니다."

EF는 충분히 성숙하여 많은 사람들이 성공적으로 사용했습니다. EF가 두통에 지나지 않는다고 주장하는 사람은 아마도 EF를 올바르게 사용하는 방법을 배우기 시작해야 할 것입니다.

그렇다면 자신 만의 ORM을 작성해야합니까?

나는 그것을 제안하지 않을 것입니다. 이미 전문가 수준의 ORM이 있으므로 다음과 같은 경우에만 직접 작성해야합니다.

• 기존의 모든 ORM이 어떤 이유로 든 적합하지 않은 정확한 맥락이 있습니다.
• 기존 ORM을 배우는 대신 자신의 ORM을 작성하고 사용하는 비용이 훨씬 더 낮습니다. 여기에는 ORM 작업 방법을 이해하기 위해 수백 페이지의 기술 문서를 읽어야하는 다른 개발자 팀을 포함한 향후 지원 비용이 포함됩니다.

물론, 호기심으로 자신의 ORM을 작성하고 사물을 배우는 것을 금지하는 것은 없습니다. 그러나 상업 프로젝트에서는 그렇게해서는 안됩니다.

또한 바퀴를 재발견하고 후회하지 말아야한다는 질문에 대한 나의 대답 의 2 ~ 3 장을 참조하십시오 . 휠을 재발 명하는 다른 이유가 여기에 적용되지 않음을 알 수 있습니다.

모든 일반 CRUD 항목 (코드의 80-95 %)에 Entity Framework를 사용하고 최적화해야하는 나머지 코드에 대해서는 사용자 지정 데이터 액세스 코드를 사용 하십시오. 충분한 통제력이 없다고 주장하는 사람들의 우려를 충족시켜야합니다.

처음에는 해당 코드를 생성하는 데 필요한 코드를 직접 작성하여 최소한의 시간 / 노력을 절약 할 수 있다면 (적어도 합리적으로) 확신 할 수있는 것이 좋습니다. 상황에 따라 그렇게하는 것도 일정에 영향을 줄 수 있으며이를 고려해야합니다. 또한 장기 유지 보수를 방정식에 고려해야합니다. 자신의 ORM을 롤링하는 경우 영구적으로 (또는 최소한 사용하는 한) 유지해야합니다.

결론 은 올바른 조건 하에서 이해 될 수 있다는 것 입니다. 이러한 조건에는 일반적으로 다음이 포함됩니다.

1. 작업중 인 프로젝트는 상당히 크기 때문에 많은 양의 사용으로 인해 비용이 상각됩니다.
2. 기존 라이브러리 (및 그와 같은)가 목적에 따라 제대로 작동하지 않는 데이터 사용은 매우 드문 경우입니다.

명백한 내용을 밝힐 위험이있는이 두 가지는 서로 역의 관계가 있습니다. 진정으로 훌륭한 프로젝트를 수행하는 경우, 각각의 개인 사용에서 약간의 비용 절감만으로도 개발을 정당화하기에 충분할 수 있습니다. 반대로, 당신의 요구가 정말로 이례적 이라면 , 매번 사용할 때마다 많은 것을 얻습니다. 작은 프로젝트조차도 정당화 될 수 있습니다.

그러나 적어도 귀하의 설명에 따르면 귀하의 경우에는 실제로 적용되지 않습니다. 아마도 하나 또는 둘 다 동료의 이전 EF 사용에 적용되었거나 아마도 그가 편견을 가지고있을 것입니다. 그가 추측하기에 거의 말하지 않았기 때문이다).

내가이 상황을 담당했다면, 나는 당신과 당신의 동료들에게 각각 일종의 입장 표를 작성하길 원한다고 생각합니다. 각 접근 방식에서 볼 수있는 강점과 약점 목록과 각 주장 / 청구를 뒷받침하는 실제 증거 /도대체 무엇이. 그런 다음 전체 팀이 각 논문을 비판 할 수있게됩니다. 그들의 비평의 주요 포인트는 각 포인트를 두 가지 척도로 평가하는 것입니다.

1. 포인트가 정확하고 사실 등으로 잘 뒷받침되는 정도
2. 포인트가 현재 프로젝트에 적용되는 것으로 보이는 정도.

그런 다음 결정을 내리기 위해 논문과 비평을 평가할 것입니다. (전적으로 정직하지만 결정을 내리기 위해 얼마나 많이 사용했는지, 결정을 정당화하기 위해 얼마나 많이 사용했는지 말하기는 어려울 수 있습니다. 나는 이미 만들었을 것입니다-아마 인정해서는 안된다는 것을 알고 있지만 실제로는 나도 인간입니다 ...)

편집하다:

특히 불쾌감을 원한다면 (또는 "교육적"-이 경우의 차이점을 말하기 어렵습니다) 기존 ORM / DAL을 사용하고 개발하는 전체 개발 노력의 추정치를 개발하려고합니다. 너 스스로. 그것은 단지 추측 일 뿐이지 만, 저의 즉각적인 추측은 그들 자신을 굴 리려는 웅대 한 계획을 가진 대부분의 사람들이 그들의 추정치를 돌리는 것을 귀찮게하지 않을 것입니다. (현실적으로) 기존 코드를 사용하여 경쟁 할 수있는 방법이 없다는 것을 깨달았습니다. 동시에

편집 2 : (@CmdKey의 제안에 따라) : 명시 적으로 언급되지는 않았지만 추정에는 암시 적으로 위험 평가가 포함된다고 가정합니다. 특히, 시간 추정에는 일반적으로 PERT 스타일 숫자가 포함되어야합니다.

1. 모든 것이 제대로 되었다면 가장 빠른 추정치입니다.
2. "정상적인"추정치-예상 시간
3. 모든 것이 잘못되었을 경우 가장 오래 걸리는 최악의 경우입니다.

물론, 최상의 경우와 최악의 경우는 일반적으로 직접적인 신의 개입과 같은 것을 포함해서는 안되지만, 그보다 짧은 것은 포함해야합니다.

일반적으로 바퀴를 재발 명하는 것은 좋은 생각이 아니며 그렇게하는 것은 일반적으로 기술적 인 무지 ( "나는 다른 것을 알지 못하고 배우고 싶지 않습니다") 또는 오만 ( "X는 바보입니다. 2 주 안에 나만의 도구를 쓰십시오! "); 일부 일반 개발자가 몇 주 안에 함께 해킹 할 수있는 것보다 훨씬 더 나은 일을 할 수있는 성숙한 도구가 있습니다.

그러나 많은 작업 없이도 기존 솔루션에 대해 기존 솔루션에 대해 레거시 애플리케이션을 안정적으로 맞출 수없는 경우가 있습니다. 이와 같은 경우에는 "좋은"아이디어가 아니라 대안 (즉, 그대로 두거나 써드 파티 레이어를 사용할 수 있도록 절반을 다시 쓰는 것)보다 더 나은 아이디어이므로 선택의 여지가 거의 없습니다.

필자는 Hibernate에 존재하지 않는 "중요한"기능으로 인해 기존 Java ORM 도구를 거부하여 자체적으로 작성하는 프로젝트를 진행하고있었습니다. 이것은 수백만 달러의 실수였으며 비용은 매일 증가하고 있습니다. 여전히 개체 관계를 완전히 지원하지 않습니다. 따라서 프레임 워크를 만들고 유지 관리하는 데 소요되는 모든 시간 외에도 Hibernate를 사용하여 몇 분 안에 작성 될 수있는 코드를 작성하는 데 많은 시간을 소비하고 있거나 많은 경우 전혀 작성하지 않아도됩니다.

기존 프레임 워크는 수십 년에 걸친 노력의 결과물입니다. 단 하나의 팀이 몇 주 만에 어디든지 올 수 있다고 상상하는 것은 당연합니다.

작성해야하는 코드는 유지 관리해야하는 코드입니다. ORM 코드를 유지하는 데 소요 된 시간 은 앱을 유지 관리 하지 않는 데 소요 된 시간 입니다. ORM이 전략적 이점을 제공하지 않는 한, 비즈니스를위한 돈을 벌 수있는 것은 아니므로 순수한 오버 헤드입니다. 회사가 간접 비나 돈 버는 제품을 개선하기 위해 돈을 쓰려고합니까? 이것이 내부 응용 프로그램을위한 것이라면 이것이 문제가 아닐 수 있지만 작성, 테스트 및 문서화 해야하는 코드의 양이 계속 증가하고 있습니다.

나는 당신 자신의 ORM을 출시하는 것이 나쁜 생각이라고 말합니다.

나는 다른 사람들이 ORM을 사용하지 말라고 한 번 실수를 저지르고 모든 DAL을 직접 작성하면 실제로 속도가 느려지고 비즈니스에 중요한 기능을 구현하는 대신 DAL에 시간을 소비한다고 말할 수 있습니다 (더 많은 작업입니다) 보이는 것보다).

새로운 EF sems는 꽤 훌륭하지만 더 많은 제어를 원한다면 Drapper http://code.google.com/p/dapper-dot-net/ 또는 PetaPOCO http 와 같은 마이크로 ORM을 살펴보십시오 . : //www.toptensoftware.com/petapoco/

당신은 또한 혼합하고 일치시킬 수 있습니다-대량의 물건에는 EF를 사용하고 미세 조정에는 Drapper를 사용하십시오.

어쨌든 그것은 단지 내 2c입니다.)