EF 4.1에서 DBSet <Something> 대신 DBSet <ISomething>을 사용할 수 있습니까?

Question

나는 비지니스 모델을 가진 도메인 모델을 만들고 EF 4.1이 나를 위해 영속성을 갖도록하려고한다. 여태까지는 그런대로 잘됐다.

문제는 모든 도메인 클래스에서 모든 속성이 공개로 노출된다는 것입니다. 어쨌든 튜토리얼에서 배운 것은 최소한입니다. 즉, 비즈니스 메서드가 아닌 부주의 한 프로그래머가 클래스 속성을 변경하지 않는다는 강력한 증거는 없습니다. 캡슐화가 위반되었습니다.

내가 뭔가를 소개했는데 TableAttribute는 인터페이스가 아니라 클래스에만 적용되므로 EF에 DBSet을 알릴 수 없습니다. 클래스에 TableAttribute를두고 있지만 어쨌든 뭔가를 구현하면 EF가 ISomething을 모르기 때문에 DBSet.Add()를 수행 할 수 없습니다.

내가 생각할 수있는 유일한 방법은 인터페이스를 사용하는 CRUD 용 EF 4.1 맨 위에 완전한 추상화 레이어를 작성하는 것입니다. 후드 아래에서 Something과 Isomething 사이의 형식 변환을 수행합니다. 그것은 EF의 디자인에 많은 복잡성과 커다란 구멍을 냈습니다. 아니면 뭔가 놓친 것 같아.

어떻게 해결할 수 있습니까?

감사합니다.

Answer 1

문제는 모든 도메인 클래스에서 모든 속성이 공개로 노출된다는 것입니다. 어쨌든 튜토리얼에서 배운 것은 최소한입니다. 즉, 은 비즈니스 메서드 외부의 부주의 한 프로그래머 인 에 의해 클래스 속성이 변경되지 않는다는 강력한 증거가 없음을 의미합니다. 캡슐화 이 위반되었습니다.

어떻게 인터페이스로 해결할 수 있습니까? Interface는 public으로 모든 프로퍼티를 다시 노출 할 것이고 EF는 프로퍼티가 getter와 setter를 가져야한다고 요구합니다.

EF는 인터페이스에서 작동하지 않습니다. 매핑을 위해 EDMX를 사용할 때 속성의 접근성을 사용하여 약간의 작업을 수행 할 수 있지만 먼저 코드를 사용할 때는 매핑이 동일한 접근성 규칙의 영향을 받기 때문에 훨씬 더 나쁩니다. EF 위에 추상화 레이어를 만드는 것은 EF를 전혀 사용하지 않는 것과 거의 같습니다. 일단 추상화를 만들면 linq-to-entities를 직접 사용할 수 없으며 EF 사용의 주된 이유를 잃게됩니다.

문제는 다음과 같습니다. 경계는 어디에 있습니까? 비즈니스 메서드에서만 엔터티를 사용하여 작업하려면 이러한 메서드에서 엔터티를 노출하지 않아야합니다. 속성이 올바르게 처리되었는지 확인하려면 아마도 유효성 검사 로직을 엔터티에 직접 구현해야합니다.