현재 빌드중인 응용 프로그램은 저장 프로 시저와 수작업으로 만든 클래스 모델을 사용하여 데이터베이스 개체를 나타냅니다. 일부 사람들은 Entity Framework 사용을 제안했으며 프로젝트에 그리 멀지 않기 때문에 Entity Framework로 전환하는 것을 고려하고 있습니다. 내 문제는 EF를 주장하는 사람들이 나에게 좋은 면만 알려주고 나쁜면은 아니라고 생각합니다. :)
나의 주요 관심사는 :
- 우리는 DataAnnotations를 사용하여 클라이언트 측 유효성 검사를 원하며, 어쨌든 클라이언트 측 모델을 작성 해야하는 것처럼 들리므로 EF가 코딩 시간을 크게 절약 할 것이라고 확신하지 못합니다
- 네트워크를 통과 할 때 클래스를 최대한 작게 유지하고 싶습니다. EF를 사용하면 필요하지 않은 추가 데이터가 포함되는 경우가 많습니다.
- 여러 데이터베이스를 교차하는 복잡한 데이터베이스 계층이 있으며 EF가이를 처리 할 수 있는지 잘 모르겠습니다. 우리는 사용자, 상태 코드, 유형 등과 같은 것들을 가진 하나의 공통 데이터베이스와 응용 프로그램의 다른 인스턴스에 대한 주 데이터베이스의 여러 인스턴스를 가지고 있습니다. SELECT 쿼리는 모든 데이터베이스 인스턴스에서 쿼리 할 수 있으며 쿼리 할 수 있지만 사용자는 현재 작업중인 데이터베이스에있는 개체 만 수정할 수 있습니다. 응용 프로그램을 다시로드하지 않고도 데이터베이스를 전환 할 수 있습니다.
- 객체 모드는 매우 복잡하며 종종 몇 가지 조인이 관련됩니다.
EF의 주장은 다음과 같습니다.
- 동시성. 저장하기 전에 레코드가 업데이트되었는지 확인하기 위해 코드를 작성할 필요가 없습니다.
- 코드 생성. EF는 나를 위해 부분 클래스 모델과 POCO를 생성 할 수 있지만 유효성 검사 및 일부 사용자 정의 구문 분석 방법을 위해 클라이언트 측 모델을 작성해야한다고 생각하기 때문에 시간이 많이 절약됩니다.
- 모든 데이터베이스 개체에 대해 CRUD 저장 프로 시저를 만들 필요가 없으므로 개발 속도
현재 아키텍처는 매개 변수가있는 저장 프로 시저를 통해 데이터베이스 호출을 처리하는 WPF 서비스, WCF 서비스 및 WPF 클라이언트를 오가는 POCO 개체 및 유효성 검사 및 POC를 위해 POCO를 클래스 모델로 변환하는 WPF 데스크톱 클라이언트 자체로 구성됩니다. 데이터 바인딩.
제 질문은 EF가 이것에 맞습니까? 내가 알지 못하는 EF에 대한 함정이 있습니까?
성능과 LINQ 지원 비교 : ormeter.net
—
M.Sameer