저는 Entity 모델에 익숙하지 않습니다. 저는 Entity 모델을 구성하는 방법에 대한 조언을 찾고 있습니다.여러 개의 edmx 파일과 하나의 큰 edmx 파일 사용
내가 등을 하나 개의 엔티티 모델 파일 (.edmx) 내 데이터베이스의 모든 테이블을 포함하거나 내가 사용자, 주문, 제품 그것을 논리 파일을 중단해야 만들어야합니다
은 알려 주시기 바랍니다 어느 각 대안의 장점/단점 (있는 경우).
감사합니다.
모든 엔티티가 포함 된 하나의 큰 EDM을 갖는 것이 일반적으로 좋지 않으며 권장되지 않습니다. 각 세트는 관련이 없으며 다른 세트와의 연결이 끊어져있는 동안 관련 오브젝트를 각각 포함하는 서로 다른 도메인 모델 세트가 있어야합니다.
Does it make sense to create a single diagram for all entities?
내가 우리가 우리의 프로젝트에 여러 edmx 파일을 보관해야한다고 생각 :
내가 구체적으로이 문제를 설명이 게시물을 살펴보십시오. 1-edmx 파일과 같습니다. 하나의 집합체 (관련 개체 모음)입니다. ddd (도메인 드라이브 디자인) 당 우리는 우리 모델에서 하나 이상의 집계를 가질 수 있습니다. 우리는 각각의 집합에 대해 하나의 edmx 파일을 유지할 수 있습니다.
여기에 곡물에 반대 할 것입니다. 필자는 이제 EF로 2 개의 대형 응용 프로그램을 작성했습니다. 하나는 단일 edmx이고 다른 하나는 여러 개입니다. 장점과 단점이 있지만 일반적으로 나는 하나의 edmx로 삶이 훨씬 쉬워 짐을 발견했다. 그 이유는 처음부터 앱이 보이더라도 앱 내에 도메인이 실제로 분리되어 있지 않기 때문입니다. 새로운 요구 사항이 나타나면 다른 edmx의 엔티티와 관련 지을 묻는 메시지가 나오면 리팩터링하고 계속해서 주변을 이동해야합니다.
divm에 대한 모든 인수는 곧 EF 5 introduces Multiple Diagram 일 때 쓸모 없게됩니다.이 것은 edmx 파일을 처음으로 나누는 유일한 이점입니다. 당신은 당신이 노력하고 있지 않은 모든 것을 볼 필요가 없으며 성능에 영향을 미치기를 원하지 않습니다.
분할 된 edmx로 내 응용 프로그램에 이제 탐색 속성의 이점을 얻기 위해 일부 중복 엔티티가 있습니다. 어쩌면 앱에 도메인이 실제로 분리되어 있지만 대개 모든 것이 사용자에게 연결됩니다. 지금 두 가지를 병합하는 것을 고려하고 있지만 많은 작업이 필요합니다. 그래서 나는 그것이 문제가 될 때까지 함께 지켜야한다고 말할 것입니다.
모델은 테이블이 아니라 엔티티에 관한 것이어야합니다. –