다음은 실제 프로젝트에서 마주친 ADO.NET Entity Framework(이하 EF) 1.0의 주요 문제점이다. 그간의 문제점 먼저 짚어야 이야기 풀기가 용이할 듯 해서리... 이렇게 돌아서 간다.
1. POCO(Plain Old CLR Object) 미지원
•
기 사용되던 Entity 객체는 사용할 수 없다는 이야기. 신규 프로젝트에서도 자체 Entity 객체 구성이 일반적이기 때문에 EF 1.0에서 자동 생성하는 Entity 객체(이하 PAE(persistence-aware entity))는 오직 ORM(Object Relation Mapping)을 위한 부담으로 다가온다.
2. N-Tier 아키텍처 적용 시, DTO(Data Transfer Object) 수동 적용 필
•
PAE는 Navigation Property 기능으로 인해 순환 참조가 필연적으로 나타나므로, 직렬화가 불가능하다.
•
PAE는 EF 내에서 사용하는 부가 속성이 상당하기에, 이를 직렬화하면 객체 크기가 감당할 수 없을 정도로 커진다.
•
따라서 PAE는 Cross Tier 연산에 매우 부적절하며, 각 PAE에 해당하는 DTO를 새로 만들어 이를 사용해야 한다.
3. 난해한 Foreign Key의 접근 경로
•
Foreign Key에 대한 명시적 속성을 따로 지원하지 않아 EntityKey라는 PAE 고유 속성에서 상당히 복잡한 과정을 거쳐야만 Foreign Key에 접근 가능하다.
•
따라서, 개체 간 관계 설정을 이루는 방법으로 흔히 관계 설정 대상 객체를 loading하여 명시적으로 지정하게 되는데, 이는 사실 상 필요없는 DB 조회 연산이므로, 결국 자원(DB, Network, Server 모두)의 낭비를 야기하는 행위를 유발한다.
4. Cascading Delete 적용 반영 사항 미비 - xml의 직접 수정 요구
•
DB Schema 변경은 보통 EF의 위저드를 통한 Update로 edmx에 반영하게 되는데, 이 때 cascading delete/update에 대한 변경은 SSDL 영역과는 달리 CSDL 에는 반영되지 않는 버그(?)가 있다.
•
결국, 이를 반영하기 위해 직접 edmx의 CSDL 영역으로 해당 Foreign Key Constraint 정의부를 찾아가 값을 채워야 하는 '무지막지한' 노고를 요구한다.
사실, 프로젝트 처음 시작할 때만해도 ORM 도구에 대해 별로 아는 바가 없기에 MS를 믿고 EF 1.0을 택했지, 지금이라면 절대 이를 고르지 않았을 것이다. 다른 문제는 어쨌건 우회책 등이 있으니 그렇다 치고, #2에서 설명한 DTO의 필요성을 마주쳤을 때는 정말이지... 절망스러웠다. 아니, 실전 프로젝트에서 DB Table이 한둘이던가? 최소 수십여개에 이르는 Table에 대해 각각의 DTO를 손수 만들고, PAE와 DTO간 속성 매핑 노가다를 대부분의 CRUD 연산 코드에서 수행한다? 한마디로 말해 미친 짓이다.
위 MSDN Magazine의 컬럼은 DTO를 통한 EF 사용 예를 들고 있는데, 앞서 설명한 문제는 쏙~ 빼놨다. 본 컬럼 등을 보고, 믿고 프로젝트 용감하게 EF를 적용했던 나는 적용 이후 한참이나 지나서야 문제를 파악하게 되었으니. 결국 해당 프로젝트에서는 XSLT 기반으로 DTO Generator와 DTO-PAE Auto Mapper를 손수 만들어서야 문제를 해결보게 되었다(참고로 http://code.msdn.microsoft.com/EFPocoAdapter에서 이와 동일한 목적의 도구를 제공한다. 난 프로젝트 종료시점에 와서야 이를 알았다는... 썅)
여하간, 위와 같은 경험/관점을 기반으로 하여 EF 4.0의 개선 사항을 이제부터 디벼보도록 하겠다.