EF를 사용하여 ASP.Net MVC 응용 프로그램을 설계하는 방법은 무엇입니까?

Question

Entity Framework를 사용하여 MVC App을 n 계층 응용 프로그램으로 구성하는 방법을 개념화하는 데 어려움이 있습니다. 프리젠 테이션은 데이터 액세스에 대해 아무것도 몰라한다

정상, 교과서 3 계층 응용 프로그램은

데이터 액세스 -> 비즈니스 Logic- 같은> 프리젠 테이션을 보일 것입니다. EF를 사용하면 모든 레이어가 모델에 대해 알아야합니다. 그래서 내 아키텍처는 지금 내가 여기서 뭔가를 놓치고 또는 내가 잘못된 방법으로 이것에 대해 생각하고 더

Data Access->Business Logic 
    |    | 
     --------------- 
      | 
      MVC 

암처럼 보인다?

EF 자체를 데이터 액세스 계층으로 생각하고 엔터티를 비즈니스 논리에 넣어야합니까?

Answer 1

글쎄, 내 질문에, 어떻게 MVC 응용 프로그램에서 "레이어"를 설계하는 것입니다. 이 간단한 아키텍처를 살펴보고 MVC 앱용으로 사용하고 있으며 깨끗하고 효율적으로 보입니다.

1. 프로젝트 솔루션 - 비즈니스 모델 - 비즈니스 도메인을 나타내는 POCO 클래스로 가득한 간단한 클래스 라이브러리. 여기서 데이터 주석, 검증 로직을위한 메타 데이터 클래스 등을 사용할 수 있습니다.

2. 프로젝트 - EF 기반 리포지토리 - 다른 간단한 클래스 라이브러리; 여기에 정의 된 컨텍스트 (EF 코드는 처음에는 훌륭하지만 EF 데이터베이스를 먼저 사용하거나 모델을 먼저 사용할 수 있습니다. 비즈니스 모델 클래스 라이브러리에 POCO T4 템플릿을 추가하면됩니다.) - 클래스 집합 - 리포지토리

3. 프로젝트 - 나는 보통 "ServiceLayer"또는 그렇게 (나는 더 나은 이름에 대한 제안을 위해 열려있다 :) - 그것은 리포지토리 및 다른 서비스 (별도의 프로젝트에서 구현)에 대한 인터페이스를 포함하고 내 MVC (또는 다른 기술) 기반 응용 프로그램 사용; 저장소에서 2.project 이러한 인터페이스를 구현

4. 프로젝트 - MVC 웹 사이트. Dependency Injection (DependencyResolver를 빌드하고, Ninject 컨테이너를 사용하는 것을 좋아한다)을 매핑 저장소 (및 다른 서비스)에 사용합니다. 그런 다음 컨트롤러로 생성자 주입을 사용하거나 일부 "게으른"접근 방식은

   는

그것은 다음과 같은 형태 (아래 참조) :

스키니 컨트롤러 :

 
public class SomethingController : BaseController 
{ 
    public ActionResult DoSomething(SomeBusinessThing input) 
    { 
     if (ModelState.IsValid) 
     { 
      var result = CustomerRepository.DoSomeBusinessLogicAndPersistenceAndStuff(input); 
      return View(result); // you can use AutoMapper here, if you dont want to use business object as viewmodels 
     } 
    } 
} 

내 저장소 "속성을 "내 BaseController에서 상속 :

이

 
public class BaseController : Controller 
{ 
    // ... other stuff used by all (or multiple) controllers 

    private ICustomerRepository _customerRepository; 
     protected ICustomerRepository CustomerRepository 
     { 
      get 
      { 
       if (_customerRepository== null) 
        _customerRepository= DependencyResolver.Current.GetService(); 
       return _customerRepository; 
      } 
     } 
} 

당신이 사용할 수있는"경우 게으른 "DI 당신의 컨트롤러는 많은 서비스를 사용하지만 액션 당 1 ~ 2 개만 사용하므로 생성자와 함께 모든 서비스를 주입하는 것은 비효율적입니다.누군가는 당신에게 이런 식으로 의존성을 숨기고 있다고 말할 수 있습니다.하지만이 모든 것들을 한 곳에서 지키면됩니다. BaseController는별로 중요하지 않습니다.

음, 저장소의 구현은 실제로 귀하의 비즈니스입니다. MVC 응용 프로그램도 그나마 당신이 EF를 사용하여 알고, IT 서비스의 인터페이스를 알고 구현 기저의에 대한 관리를 나던

Conslusion (당신은 당신이 필요 나중에 경우 언제든지 전환 할 수 있습니다!) :

• 컨트롤러는 스키니입니다. 비즈니스 로직 없음

• 모델은 FAT입니다.이 경우 리파지토리는 모든 비즈니스 로직을 캡슐화합니다 (물론 다른 유형의 서비스도 사용할 수 있습니다. , MVC는 신경 쓰지 않는다. (I Y 인터페이스)

• ViewModels는 뷰에 대한 입력 (와 뷰 모델은 직접 비즈니스 모델이 될 수 있습니다, 또는 당신이

Answer 2

EF 엔티티는 데이터 객체로 생각할 수 있으며 별도의 보기 모델이보기로 전달됩니다. EF 개체의 데이터를 사용하여 뷰 모델을 채울 수 있습니다 (여기서는 AutoMapper과 같은 라이브러리가 유용합니다). 이렇게하면 뷰는 EF 객체에 직접 의존하지 않으며 뷰 모델에서만 달라집니다.

Answer 3

난 당신이 정말 좋은 추천 할 수 있습니다 "순수"ViewModels)을 만들기위한 AutoMapper을 사용할 수 있습니다 생각) 도메인 구동 아키텍처 디자인에 관한 책. Book si는 .NET 4.0으로 N 계층 도메인 구동 아키텍처 가이드라고 불렀습니다. 책에서는 EF와 MVC (그리고 Silverlight, Unity와 같은 IoC 등 많은 다른 것들)를 사용하여 훌륭한 아키텍처를 만드는 방법을 설명합니다.

책이 주소에서 다운로드 할 수 있습니다

는 :

http://microsoftnlayerapp.codeplex.com/

가장 좋은 방법은 POCO 클래스 독립을 만드는 EF에 대한 엔티티를 생성하는 방법 :

http://msdn.microsoft.com/es-es/architecture/en/

또한 샘플 응용 프로그램은 매우 흥미 롭다 영구 층에. 이러한 도메인 엔터티는 도메인 (비즈니스) 논리 계층에 포함됩니다.

또한 응용 프로그램은 프레젠테이션, 적용, 도메인, 인프라 (데이터 지속성 대부분), 교차 절단 및 분산 서비스 계층을 설명하는 더 많은 계층으로 나누어 져야한다고 설명합니다.