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

StackOverflow https://stackoverflow.com/questions/235233

문제

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 패턴 및 관행. 그리고 나는 속담을 '그림은 천 단어의 가치가 있습니다'라고 믿습니다.

Diagram shows architecture of MVC and business sevices layers

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

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

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

더 긴 대답은 컨트롤러에서 모델로 로직을 이동하기 전에 모델 계층의 디자인에 대해 어느 정도 생각해야 한다는 것입니다.아마도 REST를 사용하여 모든 앱 로직을 처리할 수 있을 것입니다. 이 경우 모델의 디자인은 상당히 명확해야 합니다.그렇지 않다면 모델이 비대해지는 것을 방지하기 위해 어떤 접근 방식을 사용할 것인지 알아야 합니다.

Stephen Walther 의이 멋진 튜토리얼을 확인할 수 있습니다. 서비스 계층으로 검증.

컨트롤러 동작과 별도의 서비스 계층으로 유효성 검사 로직을 이동하는 방법에 대해 알아보십시오. 이 튜토리얼에서 Stephen Walther는 서비스 계층을 컨트롤러 계층에서 분리하여 우려 사항을 급격히 분리 할 수있는 방법을 설명합니다.

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

  1. 도메인 엔티티를 찾으십시오
  2. 도메인 엔티티에서 행동하십시오
  3. 보기 / 반환 결과를위한 데이터를 준비하십시오

또한 컨트롤러에는 일부 응용 프로그램 논리가 포함될 수 있습니다.

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

모델이란 무엇입니까? 이제 좋은 질문입니다. 참조하십시오 Microsoft 패턴 및 관행 기사 (우수한 찾기를 위해 Alejandror에게 Kudos). 여기에는 세 가지 범주의 모델이 있습니다.

  • 모델보기: 이것은 단순히 데이터 백으로, 데이터가 최소화 된 경우 데이터가 최소화되어 있으며, 뷰에서 데이터를 전달하는 논리에는 기본 필드 검증이 포함되어 있습니다.
  • 도메인 모델: 비즈니스 로직이있는 지방 모델은 단일 또는 여러 데이터 엔티티에서 작동합니다 (즉, 엔티티의 조치보다 주어진 상태의 엔티티 A)
  • 데이터 모델: 스토리지 인식 모델, 단일 엔티티 내에 포함 된 논리는 해당 엔티티 와만 관련됩니다 (즉, 필드 A 당시 필드 B)

물론 MVC는 다양한 품종으로 나오는 패러다임입니다. 여기서 설명하는 것은 MVC가 최상위 레이어 만 점유하는 것입니다. Wikipedia에 관한이 기사

오늘날 MVC 및 유사한 모델-뷰-프리 센터 (MVP)는 더 큰 시스템의 프리젠 테이션 계층에만 적용되는 관심 설계 패턴의 분리입니다. 간단한 시나리오에서 MVC는 시스템의 기본 설계를 나타내며 데이터베이스에 직접 도달 할 수 있습니다. 그러나 대부분의 시나리오에서 MVC의 컨트롤러와 모델은 서비스 또는 데이터 계층/계층에 대한 의존성이 느슨합니다. 이것은 클라이언트-서버 아키텍처에 관한 것입니다

의존성 인젝터를 사용하면 비즈니스 로직이 그들에게 이동하므로 깔끔하고 깨끗한 컨트롤러가됩니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top