ASP.NET MVC-비즈니스 로직이 컨트롤러에 있어야합니까?

Derik Whitaker는 며칠 전에 제가 한동안 궁금해했던 기사를 게시했습니다 . 비즈니스 로직이 컨트롤러에 있어야 하는가?

지금까지 내가 본 모든 ASP.NET MVC 데모는 컨트롤러에 리포지토리 액세스 및 비즈니스 논리를 넣었습니다. 일부는 거기에도 유효성 검사를 던집니다. 이로 인해 컨트롤러가 상당히 커지고 부풀어집니다. 이것이 정말로 MVC 프레임 워크를 사용하는 방법입니까? 이것은 다른 컨트롤러에 분산 된 많은 중복 코드와 로직으로 끝날 것 같습니다.

비즈니스 로직은 실제로 모델에 있어야합니다. 당신은 뚱뚱한 모델, 마른 컨트롤러를 목표로해야합니다.

예를 들어 다음을 갖는 대신 :

public interface IOrderService{
    int CalculateTotal(Order order);
}

차라리 :

public class Order{
    int CalculateTotal(ITaxService service){...}        
}

이는 세금이 외부 서비스에 의해 계산되고 모델이 외부 서비스에 대한 인터페이스에 대해 알아야한다고 가정합니다.

그러면 컨트롤러가 다음과 같이 보입니다.

public class OrdersController{
    public OrdersController(ITaxService taxService, IOrdersRepository ordersRepository){...}

    public void Show(int id){
        ViewData["OrderTotal"] = ordersRepository.LoadOrder(id).CalculateTotal(taxService);
    }
}

아니면 그런 것.

Microsoft Patterns & Practices에서 제공하는 다이어그램이 마음에 듭니다 . 그리고 저는 '사진은 천 마디의 가치가있다'는 속담을 믿습니다.

이것은 흥미로운 질문입니다.

많은 샘플 MVC 응용 프로그램이 실제로 "비즈니스 논리"를 모델에 완전히 배치한다는 의미에서 MVC 패러다임을 따르지 못하는 것이 흥미 롭다고 생각합니다. Martin Fowler는 MVC가 Gang Of Four의 의미에서 패턴이 아니라고 지적했습니다. 오히려 프로그래머가 장난감 앱 이상의 무언가를 만들 때 패턴 을 추가해야하는 것은 패러다임입니다 .

따라서 짧은 대답은 "비즈니스 로직"이 실제로 컨트롤러에 있으면 안된다는 것입니다. 컨트롤러에는 뷰 및 사용자 상호 작용을 처리하는 추가 기능이 있고 우리는 하나의 목적으로 만 개체를 ​​만들고자하기 때문입니다.

더 긴 대답은 컨트롤러에서 모델로 로직을 이동하기 전에 모델 레이어의 디자인에 약간의 고려를해야한다는 것입니다. REST를 사용하여 모든 앱 로직을 처리 할 수 ​​있으며,이 경우 모델의 디자인이 상당히 명확해야합니다. 그렇지 않은 경우 모델이 부풀어지지 않도록하기 위해 사용할 방법을 알아야합니다.

서비스 계층으로 유효성 검사 를 보여주는 Stephen Walther의이 멋진 자습서를 확인할 수 있습니다 .

컨트롤러 작업에서 별도의 서비스 계층으로 유효성 검사 논리를 이동하는 방법을 알아 봅니다. 이 튜토리얼에서 Stephen Walther는 컨트롤러 계층에서 서비스 계층을 분리하여 우려 사항을 뚜렷하게 분리하는 방법을 설명합니다.

비즈니스 로직은 컨트롤러에 포함되어서는 안됩니다. 컨트롤러는 가능한 한 얇아 야하며 이상적으로는 패턴을 따라야합니다.

1. 도메인 엔티티 찾기
2. 도메인 엔티티에 대한 조치
3. 결과보기 / 반환을위한 데이터 준비

또한 컨트롤러에는 일부 애플리케이션 로직이 포함될 수 있습니다.

그렇다면 비즈니스 로직은 어디에 두어야합니까? 모델에서.

모델이란? 이제 좋은 질문입니다. 참조하시기 바랍니다 마이크로 소프트 패턴 및 사례 기사 (우수 찾기위한 AlejandroR로 명성을). 여기에는 세 가지 범주의 모델이 있습니다.

• View Model : 이것은 단순한 데이터 백이며, 뷰에서 데이터를 전달하기위한 최소한의 논리가있는 경우 기본 필드 유효성 검사를 포함합니다.
• 도메인 모델 : 비즈니스 로직이있는 팻 모델, 단일 또는 다중 데이터 엔티티에서 작동합니다 (즉 엔티티 B에 대한 조치보다 주어진 상태의 엔티티 A).
• 데이터 모델 : 스토리지 인식 모델, 단일 엔티티 내에 포함 된 논리는 해당 엔티티에만 관련됩니다 (즉, 필드 a 다음 필드 b).

물론 MVC는 다양한 종류의 패러다임입니다. 내가 여기서 설명하는 것은 MVC가 최상위 레이어 만 차지하는 것 입니다. Wikipedia에서이 기사를 참조하십시오.

오늘날 MVC 및 유사한 MVP (Model-View-Presenter)는 더 큰 시스템의 프레젠테이션 계층에만 적용되는 우려 사항 분리 디자인 패턴입니다. 간단한 시나리오에서 MVC는 데이터베이스에 직접 도달하는 시스템의 기본 설계를 나타낼 수 있습니다. 그러나 대부분의 시나리오에서 MVC의 컨트롤러 및 모델은 서비스 또는 데이터 계층 / 계층에 대해 느슨한 종속성을 갖습니다. 이것은 클라이언트-서버 아키텍처에 관한 것입니다.

Dependency Injectors를 사용하면 비즈니스 로직이 그들에게 전달되므로 깔끔하고 깨끗한 컨트롤러를 얻을 수 있습니다.