먼저 POCO 지원에 대해서 썰풀어 본다
위 컬럼에서 나오는 직접 생성한 Entity 클래스를 보자. 부가 속성이 전혀 없는 POCO 그대로이다. 당연스럽게도 LINQ를 통한 편리한 조회 연산에서 CUD(Create Update Delete) 연산까지 모두 지원한다. 또한 POCO 생성 도구 역시 지원하는데, 이는 따로 설치해야 하며 해당 템플릿은 요기에서 받으면 된다. 템플릿은 T4(Text Template Transformation Toolkit) 기반이며 당연히 수정 가능하기에 입맛대로 여러 spec을 끼워 프로젝트에 적용하면 되겠다. 슬쩍 보니 사용법 익히는데 그리 많은 시간이 필요할 것 같지는 않다(XSLT 기반보다는 훨 쉬워 보인다).
1.0에서 사용되던 PAE는 기존과 동일하게 사용 가능함과 동시에 POCO 템플릿처럼 따로 Generator가 기본 제공된다. 또한 Self-Tracking Entity(이하 STE) Generator가 추가되었는데, STE는 변경 사항 추적을 위한 장치가 달려있다(INotifyPropertyChanged 및 IObjectWithChangeTracker란 interface를 기본 상속받도록 구성되어 있는데, PAE와 마찬가지로 역시 직렬화 시에 크기가 만만치 않게 커질 듯 해 보인다. 첨에는 이게 기본 제공되는 POCO인줄 알았다). 이놈은 나도 좀더 뒤져봐야 하는데, 하나 첨언하자면 PAE가 지원하는 Lazy Loading을 지원 안한다(MS가 난데없는 Deferred Loading란 요상한 신조어를 쓰더니만, VS2010 정식 버전에선 Lazy Loading으로 다시 바꿨다. 필요없이 사람 홀리는 쓰래기짓 한다고 욕좀 먹고 복귀한 듯 하다. 그런 인간들... 내 주위에 좀 보인다. 피곤하다).
둘째, DTO 필요성에 대해서
POCO를 DTO로 사용하면 되므로 기존에 이를 위했던 작업은 전혀 필요 없다. STE도 DTO로 사용 가능할 듯 보이는데(실제 WCF 등을 위한 DataContract 특성이 기본적으로 달려 나온다), 앞서 언급했듯이 부가된 추적 장치의 크기가 어찌될지가 변수이다. 여하간 이는 좀더 뒤져봐야 한다.
서두에서도 언급했지만 DTO가 되기 위해서는 해당 DTO에 순환 참조가 없어야 하는데, POCO에서건 STE에서건 ObjectContext를 통한 조회 연산이 이루어지면 순환 참조가 필연적으로 달려 나온다. 이는 별 수 없다. 직렬화 직전에 손수 끊어 주어야 하겠다(참고로, 이를 위한 자동화 도구는 나타나기 어려울 듯 싶다. 자동화를 하려면 유효절차가 있어야 하는데, 본 유효절차는 Business Logic에 의존할 가능성이 농후하기 땜시).
셋째, Foreign Key 접근 방법에 대해서
Entity Generator에서 아예 Foreign Key에 대한 Property를 생성할 것인지를 물어본다. 한마디로 말해 Navigation Property 이외에도 명시적인 해당 Foreign Key가 Scalar Property로 빠져나온다는 뜻이다.
넷째, Cascading Delete 적용 반영 사항 미비 건에 대해
기존에는 없던 Model Designer에 해당 Relationship에 대한 Cascading Delete 옵션이 명시적으로 달려있다. 따라서 xml 코드를 뒤지는 노가다는 더이상 필요 없다. 다만 DB Schema 변경에 대한 edmx 갱신 시 본 사항이 반영 안되는 버그(?)는 여전하다(EF 개발팀에서 본 문제를 모를리 없을 터인데, 뭔가 딴 이유가 있는지도 몰라 '?'를 붙였다).
요기까지가 앞서 설명했던 1.0의 문제점에 대한 4.0의 개선 사항이다. #4가 좀 거슬리기는 하지만 전반적으로 깔끔하게 해결되었다 할만하다. 굿이다. 이제 추가된 타 기능에 대해서 짚어볼 터인데 이들 기능이 아주 맛이 좋다. 1.0에서 4.0으로 버전 뻥튀기를 할만큼? 거기까지는 잘 모르겠지만 여하간 난 맛 좋게 느낀다.