엔티티 프레임 워크를 사용할 때 부분 클래스를 비즈니스 계층으로 사용해야합니까?

Question

저는 엔티티 프레임 워크를 사용하는 프로젝트 작업을하고 있습니다. EF 생성 클래스의 부분 클래스를 비즈니스 계층으로 사용하는 것이 괜찮습니까? 이것이 EF가 사용되는 방법이라고 생각하기 시작했습니다.

필자는 DTO 패턴을 사용하려고 시도했는데 곧 내 노력을 복제하는 매핑 클래스를 추가하고 더 많은 유지 관리 작업과 추가 레이어를 만들 수 있다는 것을 깨달았습니다.

자기 추적 엔티티를 사용하고 모든 레이어에 EF 엔티티를 전달하고 싶습니다. 생각과 아이디어를 공유하십시오. 고마워.

Answer 1

나는 그것을하지 않을 것이다. 가능한 한 레이어를 독립적으로 유지하십시오. 따라서 데이터베이스 스키마를 조금만 변경해도 모든 계층에 영향을 미치지는 않습니다.

데이터 계층에는 엔터티를 사용할 수 있지만 반드시 사용해야합니다. 전혀 사용할 인터페이스를 제공하고 BL이 엔티티가 아니라 인터페이스를 알고 있어야하는 (부분 파일에서) 엔티티를 구현하도록하십시오.

Answer 2

부분 수업은 좋은 아이디어라고 생각합니다. 모델이 다시 생성 된 경우 부분 클래스에서 비즈니스 로직을 잃지 않습니다.

EF4 코드 만 볼 수도 있으므로 데이터베이스에서 모델을 생성 할 필요가 없습니다.

Answer 3

나는 다음과 같은 이유로, 그렇게 할 것입니다 : 그것은 더 어려운 비즈니스 계층을 만드는

는 을 테스트

1. 당신은 데이터 계층과 비즈니스 계층 사이의 명확한 구분을 풀어

   그러나 데이터 모델 특정 코드가있는 경우 코드를 다시 생성 할 때 코드가 손실되지 않도록 부분 클래스로 지정하십시오.

Answer 4

부분 클래스를 사용합니다. DDD-ish 코드에는 데이터 영역과 같은 것이 없습니다. 데이터 계층이 있으며 SQL Server에 상주합니다. 응용 프로그램 코드에는 비즈니스 계층과 언급 된 데이터 계층에서 지속되는 비즈니스 개체를 허용하는 일부 매핑 만 포함되어야합니다.

Entity Framework는 데이터 액세스 코드이므로 직접 작성하지 않아야합니다. 대부분의 경우 모델이 변경되었으므로 데이터베이스 스키마가 수정됩니다. 반대가 아닙니다.

그렇다고해서 모든 항목에서 귀하의 항목을 공유하는 것이 좋습니다. 나는 UI와 도메인 계층의 분리를 중시한다. DTO를 사용하여 도메인 내부 및 외부로 데이터를 전송합니다. 필요한 자유가 있다면 CQRS 패턴을 사용하여 DTO 매핑 엔티티를 제거 할 수도 있습니다. UI 용 데이터를 읽는 데 필요한 두 번째 EF 데이터 액세스 프로젝트를 만들면됩니다. 동일한 데이터베이스 위에 구축됩니다. 읽기 (비즈니스 논리가없는 빈혈) 모델을 통해 데이터를 읽지 만 EF 및 부분 메소드를 사용하여 구현 된 실제 모델에 대해 실행되는 명령을 실행하여 수정할 수 있습니다.

귀하의 질문에 대한 답변이 있습니까?

Answer 5

부분 클래스를 사용하여 보았는데 데이터베이스 모델을 UI 레이어쪽으로 노출시키는 것이 제한적이라는 것을 알았습니다.몇 가지 이유를 들어

:

1. 생성 된 개체 모델은 스키마에 따라 UI 계층에 노출 얻을 것이다, 깊은 관계 객체 모델 (MVP의 발표자 또는 MVVM에서의 ViewModel 말을 포함).
2. 비즈니스 로직 계층은 일반적으로 사용자가 코딩 할 수있는 작업을 노출합니다. BLL에 저장 메소드가 표시되고 저장을 수행하는 데 필요한 매개 변수를보고 저장을 수행하기 위해 다른 엔티티 (관계형 속성 인 엔티티 모델의 원인)를 필요로하는 모델을 보게되면 저장하지 않습니다 수술은 간단합니다.
3. 웹 서비스가 많은 경우 명백한 이득이없이 추가 데이터를 보내야합니다.
4. 응용 프로그램의 다른 부분에서 동일한 인스턴스가 수정되어 부작용이 발생하지 않고 작업 매개 변수에 더 많은 불변 DTO를 만들 수 있습니다.

5. TDD를 수행하고 YAGNI를 따르는 경우 작성중인 작업에 맞게 특별히 설계된 구조를 가지므로 테스트를 쉽게 구성 할 수 있습니다 (테스트에 대해 실현되지 않은 다른 개체를 만들지 않아도되기 때문입니다. 그들은 모델에있다). 이 경우 당신은 할 수 ...

   public class Order 
   { ... 
       public Guid CustomerID { get; set; } 
   ... } 
   

대신 노출 대한 참조를 가지고있는 EF에 의해 생성 된 엔티티 모델을 사용

... 고객의

public class Order 
{ ... 
    public Customer Customer { get; set; } 
... } 

이 방법 아이디 주문을받는 작업에만 필요합니다. 왜 주문을하는 것과 관련된 작업을 위해 Customer (그리고 잠재적으로 다른 객체들도)을 만들어야합니까? 당신이 복제 및 매핑에 대한 고민하는 경우에

후 나는 느슨한 결합의 개념과 서로 독립적 인 레이어를 유지 이해 Automapper