Model-First Development
•
이게 뭔 소린고 하니, edmx designer에서 DB 없이 객체지향 기반의 Entity 모델을 먼저 생성 가능하다는 이야기이다. 기존에는 ERD 등을 통한 DB Table Schema 먼저 만들고 이를 edmx에 적용하는 Database-First 기반이었다. edmx designer를 통해 클래스 다이어그램을 만들고 DB 생성 명령을 내리는 순간, 해당 DB 생성 SQL script가 명시적으로 생성되며, 이를 갖고 DB를 생성하게 된다. 물론 기존 방식 역시 그대로 지원한다. 나 같이 DB가 아닌 Application 개발 출신에게는 이게 딱이다.
•
자동 생성되는 Table Schema의 Naming 역시 흠잡을 곳이 별로 없고, 상속/연관 관계 모두 DB 관점의 관계로 적절히 변환한다. 1:N, N:N, 1:1, 0..1:N 모두에 대해 역시나 잘 변환한다. cascading delete에 대한 처리는 명시적으로 따로 해주어야 한다.
다양한 Entity 타입 및 T4 기반 Entity 코드 생성
•
기존에는 사용 가능 Entity로 PAE만 있었지만 이제는 세가지로 늘어났다. 각 Entity의 특성에 따라 입맛대로 사용하면 된다는 뜻. 또한 앞에서도 언급했지만, T4 기반으로 PAE, STE, POCO Entity 코드 모두를 생성하게 되는데, 생성 코드가 노출되어 있으므로 적절한 커스터마이징이 가능하다는 이야기이다. 이렇듯 변경되다보니 Entity 코드 파일은 edmx 하위가 아닌 tt(T4 파일) 파일 하위에 위치하게 된다.
IntelliTrace - 대박!
이게 VS2010의 고유 기능인지, EF에서만 쓰이는 건지 잘 모르겠지만, 한마디로 BIG POT이다. 뭐가?
EF를 만지작거리다보면 실제 SQL Query문 사용할 일이 없어지기에 과연 어떻게 query가 날라갈지 항시 고민하게 되는데, 이게 해당 SQL query문을 보여주는 것이다. EF 연산 문장 밑에 break point 찍고 해당 문장까지 실행하면 당장에 나타난다.
이게 없으면 SQL Profiler를 따로 돌려서 확인하는 매우 번잡스러운 프로세스를 거쳐야 한다. EF가 편하기는 하지만 이로 인해 DB로 날릴 query는 난잡해질 가능성이 아주 농후한데(DB Admin이 보면 난리를 칠 요소가 곳곳에 배치되어 있다), 이를 통해 LINQ Tuning, 즉 SQL Tuning이 매우 용이해진다. EF에 익숙하지 않은 사람에게는 이건 필수 기능이다.
Entity 자동 생성 시 의 복수/단수 자동 설정
•
1.0에서 행했던 삽질 중 하나가 collection으로 빠지는 Property에 대해 끝에다가 's'를 붙이는 작업이었는데(난 Entity 명칭 등의 다른 명칭은 자동 생성된 그대로 두었다. 대부분 DB Schema에 정의된 명칭을 그대로 사용하여 생성한다), 본 삽질이 필요없어졌다는 이야기.
이 외에도 많은 기능이 개선/추가된 듯 한데, 나머지는 내가 경험하지 못한 거니 패스~. 자세한 사항은 http://blogs.msdn.com/efdesign/archive/2010/04/12/announcing-the-release-of-entity-framework-4.aspx를 참고하시도록.
어쨌건, EF 1.0으로 꽤나 고생했던 바라 그 유명한 NHibernate로 옮겨 타볼까 생각하고 있었는데, EF 4.0을 맛보고 나니 그 마음이 쑥~ 들어갔다고 하기는 그렇고, EF에 대한 반감이 상당한 호감으로 변했음은 부인할 바 없다. 허나 NHibernate와 EF 4.0을 비교한 몇몇 컬럼에서도 보이듯이, 전반의 분위기는 여전히 NHibernate에 손을 들어주는 형편인데 가능하다면 함께 비교해보고 ORM 도구를 선택하는게 현명한 판단이 아닐까 한다.
EF를 통한 ORM 도구를 사용하면서 느낀 생각과 tip
1.
ORM 도입은 DB의 무결성 수준 증대에도 많은 도움이 되는 듯 하다. 이게 뭔 소린고 하니, ORM 도구로 인해 FK를 통한 참조 무결성을 이루기가 매우 용이해질 뿐 아니라, 해당 도구가 암묵적으로 참조 무결성을 이루도록 유도한다는 뜻이다. 국내의 일반적 DB 설계 프랙티스를 생각해보자. FK를 사용하는 곳이 과연 얼마나 되던가! 결국, 정석 DB 설계를 유도한다는 뜻이다.
2.
EF를 사용하면서 자동 생성되는 SQL Query로 인한 성능 이슈가 늘 맘에 걸렸는데(자동화와 성능은 일반적으로 반비례 관계 아니던가), EF를 적절히만 사용한다면 로 인해 성능이 더 나아질 수 있다는 생각으로 시간이 지나며 바뀌었다. 핵심은 EF가 지원하는 Lazy Loading과 DB CRUD 연산에 대한 수준 높은 접근성에 있다. LINQ 구문으로 SQL 문장을 대체하는 DB와 Application간 간극의 제거는 다양한 수준에서 SQL Query 생성을 용이하게 하는 효과를 낳는다.
3.
#2에 연계되는 이야기인데, LINQ의 Select 문을 쓰지 않으면 필요없는 컬럼의 데이터까지 모두 긁어오는 부하가 걸리므로, 되도록이면 Select()를 사용하는 편이 났다. SQL Querying에서 '*' 사용하지 말라는 기초적 튜닝 프랙티스의 EF 버전이다.
4.
STE에서 cascading delete 설정을 하면 컴파일 오류가 뜬다. 이거 해당 template의 버그란다. 해결 방법은 http://connect.microsoft.com/VisualStudio/feedback/details/533301/edmxes-and-handlecascadedelete을 참고하시고(생성되는 두개의 tt 파일 중, Entity쪽 코드의 411~414번 줄과 427번 줄을 주석 처리 하란다).
덧글 백업