엔터티 프레임 워크 및 레이어 분리


12

Entity Framework에서 약간의 작업을 시도 중이며 레이어 분리에 관한 질문이 있습니다.

나는 일반적으로 UI-> BLL-> DAL 접근법을 사용하며 여기에서 EF를 사용하는 방법이 궁금합니다.

내 DAL은 대개 다음과 같습니다.

GetPerson(id)
{
    // some sql
    return new Person(...)
}

BLL :

GetPerson(id)
{
    Return personDL.GetPerson(id)
}

UI :

Person p = personBL.GetPerson(id)

내 질문은 EF가 내 모델과 DAL을 만들었으므로 EF를 내 DAL 내부에 포장하는 것이 좋습니까, 아니면 시간 낭비일까요?

EF를 감쌀 필요가 없다면 Model.esmx를 자체 클래스 라이브러리에 배치하거나 BLL에 배치하고 일부를 작동시키는 것이 좋을까요?

EF를 자신의 DAL 내부에 포장해야하는 이유를 실제로 알 수 없지만 다른 사람들이 무엇을하고 있는지 알고 싶습니다.

따라서 위의 내용 대신 DAL을 제외하고 다음과 같이하십시오.

BLL :

GetPerson(id)
{
    using (TestEntities context = new TestEntities())
    {
            var result = from p in context.Persons.Where(p => p.Id = id)            
                    select p;
    }
}

무엇을해야합니까?

답변:


13

제공하는 예제는 계층 구조가 거의 아닙니다. 나는 그것이 의도적으로 단순화 된 것을 알고 있지만 :

프레젠테이션 계층은 개인 항목과 직접 연결됩니다. 이것은 가장 간단한 경우에만 가능하며 레이어를 정의하려고 할 때는 확실하지 않습니다.

GetPerson 메서드는 각 호출에 대해 새로운 컨텍스트를 만드는 다소 나쁜 방법을 사용하고 있습니다. 생성자에서 컨텍스트를 가져와야하며 IOC 컨테이너에서 제공합니다.

내가 사용한 간단하면서도 효과적인 구조는 다음과 같습니다.

  • Project.Core-뷰 모델과 인터페이스를 포함합니다.
  • Project.DAL-내 EDMX 및 생성 된 코드와 함께.
  • Project.BLL-비즈니스 로직.
  • Project.Web-웹 앱 자체

다음 사항에 유의하십시오.

  • 코어는 다른 솔루션에 의존하지 않습니다.
  • DAL은 다른 솔루션에 의존하지 않습니다.
  • Project.Web은 Core에 의존하지만 DAL이나 BLL에는 의존하지 않습니다.
  • BLL은 Core 및 DAL에 따라 다릅니다.

1
핵심은 비즈니스 객체 계층으로 보입니다.
sq33G

이것은 또한 내가 사용하는 것과 거의 비슷하지만 인터페이스 선언을 제공하기 위해 추가 DLL을 추가합니다. 이 방법으로 인터페이스 만 참조하고 ( DI에 [url = unity.codeplex.com/]Unity[/url] 과 같은 것을 사용 하십시오) 실수로 유발 된 이상한 종속성이 없는지 확인할 수 있습니다.
Ed James

일반적으로 EF가 없으면 "모델"레이어에 자체 Person 클래스를 작성하므로 UI, BLL, DAL 및 Model이 있습니다. UI는 BLL 및 모델을 알고 있습니다. BLL은 DAL과 모델을 알고 있습니다. DLL은 Model을 알고 있습니다. 자신 만의 "뷰 모델"을 작성하고 왜 EF가 생성 한 모델을 사용하지 않습니까? (이것이 계층 구조에 위배된다는 것을 알고 있지만 실제로 데이터를 얻는 방식을 몇 번이나 전환합니까?)
Thomas

에 뷰 모델을 포장 @Thomas 뭔가 추상적 훨씬 쉽게하는 것이 단위 테스트를 할 것입니다.
sq33G

3
! 모델 = 뷰 모델
보리스 Yankov

2

EDMX를 포장 할 필요가 없습니다.

EF에서 다른 접근 방식으로 변경해야 할 가능성을 예상 할 수있는 경우 비즈니스 클래스 (부분 클래스를 활용)를 확장하여 별도의 비즈니스 오브젝트 계층에 정의 된 인터페이스를 구현할 수 있습니다.

그런 다음 코드에서 해당 인터페이스 만 처리하고 구체적으로 생성 된 클래스는 처리하지 않습니다. 이것을 붙잡기 위해 작은 접착제 코드가 필요할 수 있습니다. EDMX를 사용하면 DAL이 될 수 있습니다.


따라서 EF에서 다른 접근 방식으로 변경 사항을 예측하지 않으면 위의 코드가 정상입니까? 그런 다음 UI와 BLL 만 (EDMX가 BLL에 있음) 있습니까?
토마스

나의 실제적인 대답은 그렇습니다. 주의해야 할 점은 EDMX가 크고 정적 일 경우 실제로 작은 어셈블리에 넣기를 원할 수 있기 때문에 자주 다시 컴파일하거나 재배포 할 필요가 없습니다.
sq33G

아, 재 컴파일 / 재분배에 대한 좋은 점 :)
Thomas

2

레이어링에는 두 가지 일반적인 접근 방식이 있습니다 : 엄격한 레이어링과 완화 된 레이어링.

엄격하게 계층화 된 접근 방식은 한 계층의 구성 요소가 피어 및 하위 계층과 만 상호 작용하도록 제한합니다.

완화 된 계층화 된 응용 프로그램은 구성 요소가 하위 계층의 구성 요소와 상호 작용할 수 있도록 제약 조건을 완화합니다.

완화 된 계층화를 사용하면 시스템이 한 계층에서 다음 계층으로 간단한 호출을 전달할 필요가 없으므로 효율성을 향상시킬 수 있습니다. 반면에 완화 된 계층화를 사용하면 계층간에 동일한 수준의 격리가 제공되지 않으며 상위 계층에 영향을주지 않고 하위 계층을 교체하기가 더 어려워집니다.

많은 소프트웨어 구성 요소가 포함 된 대규모 솔루션의 경우 응집력이없는 동일한 추상화 수준에 많은 수의 구성 요소가있는 것이 일반적입니다. 이 경우, 각 계층은 하나 이상의 응집 서브 시스템으로 더 분해 될 수있다. 그림 2는 여러 서브 시스템으로 구성된 계층을 나타내는 가능한 UML (Unified Modeling Language) 표기법을 보여줍니다.

결론 : 중간 레이어가 필요하지 않으면 잃어 버리십시오. 모든 응용 프로그램에 동일한 접근 방식이 필요한 것은 아니며 계층화 목적으로 만 계층을 추가하면 복잡한 비용 및 유지 관리에 대한 불이익이 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.