ASP에서NET Core의 효율적인 컨트롤러 작성

모범 사례에 따라 더욱 좋은 컨트롤러를 만들 수 있다.이른바 '마른' 컨트롤러 (코드가 적고 직책이 적은 컨트롤러) 는 읽기와 유지보수가 더욱 쉽다.그리고 컨트롤러가 마르면 테스트를 너무 많이 할 필요가 없을 수도 있다.반대로 업무 논리와 데이터 접근 코드 테스트에 전념할 수 있다.마른 컨트롤러의 또 다른 장점은 컨트롤러의 여러 버전을 유지하기 쉽다는 것이다.
이 글은 컨트롤러를 살찌우는 나쁜 습관을 논의한 뒤 컨트롤러를 날씬하게 하고 관리하기 쉬운 방법을 모색했다.컴파일러 컨트롤러의 가장 좋은 실천은 전면적이지 않을 수도 있지만, 나는 이미 가장 중요한 부분을 토론했고, 적당한 상황에서 관련 원본 코드를 제공했다.다음 몇 절에서 우리는 뚱뚱한 컨트롤러가 무엇인지, 왜 코드가 나쁜 맛인지, 마른 컨트롤러가 무엇인지, 왜 유익한지 연구할 것이다. 그리고 컨트롤러를 어떻게 말랐는지, 간단하고 테스트 가능하며 관리할 수 있는지를 연구할 것이다.
컨트롤러에서 데이터 접근 코드 삭제
컨트롤러를 작성할 때 단일 책임 원칙을 지켜야 한다. 이것은 컨트롤러에 '하나의 책임' 이나 '있고 단지 하나의 이유만 변경할 수 있다' 는 것을 의미한다.다시 말하면, 컨트롤러 코드를 바꾸는 원인을 최소화하기를 바란다.다음 코드는 데이터 접근 논리를 갖춘 전형적인 컨트롤러를 보여 준다.
에 있습니다.NET 생태계에서 특정한 기술 창고를 사용하면 곤혹스러울 수 있다. 예를 들어 어떤 종류의 운행을 사용해야 할 때?이 문장에서 우리는 이 요점들을 모두 분명하게 말하려고 시도할 것이다.

public class AuthorController : Controller
{
    private AuthorContext dataContext = new AuthorContext();
    public ActionResult Index(int authorId)
    {
        var authors = dataContext.Authors
            .OrderByDescending(x=>x.JoiningDate)
            .Where(x=>x.AuthorId == authorId)
            .ToList();
        return View(authors);
    }
}

액션 내부에서 데이터 상하문 실례를 사용하여 데이터를 읽는 것은 단일 직책 원칙을 위반하고 컨트롤러가 거기에 나타나지 말아야 할 코드로 가득 차 있다.이 예에서는 데이터베이스의 데이터를 연결하고 처리하는 DataContext(Entity Framework Core를 사용하는 경우)를 사용합니다.
내일 데이터 접근 기술을 바꾸기로 결정하면, 컨트롤러도 바꿔야 한다.예를 들어, Dapper를 사용하여 Tier 데이터베이스에 연결하려면 어떻게 해야 합니까?더 좋은 방법은 Repository 클래스를 사용하여 데이터 접근 논리를 봉인하는 것이다. (비록 나는 Repository 모드를 별로 좋아하지 않지만.)다음 코드로 Author Controller를 업데이트합니다.

public class AuthorController : Controller
{
    private AuthorRepository authorRepository = new AuthorRepository();
    public ActionResult Index(int authorId)
    {
        var authors = authorRepository.GetAuthor(authorId);
        return View(authors);
    }
}

컨트롤러가 이제 더 말라 보여요.그러면 이것이 이 컨트롤러를 작성하는 가장 좋은 방법입니까?아니야.만약 컨트롤러가 데이터 접근 구성 요소에 접근하고 있다면, 그것은 너무 많은 일을 하기 때문에 단일 직책 원칙을 위반할 것이다.컨트롤러는 데이터 접근 구성 요소에 직접 접근하는 데이터 접근 논리나 코드가 있어서는 안 된다.다음은 Author Controller 클래스의 향상된 버전입니다.

public class AuthorController : Controller
{
    private AuthorService authorService = new AuthorService();
    public ActionResult Index(int authorId)
    {
        var authors = authorService.GetAuthor(authorId);
        return View(authors);
    }
}

AuthorService 클래스는 AuthorRepository 클래스를 사용하여 CRUD 작업을 수행합니다.

public class AuthorService
{
    private AuthorRepository authorRepository = new AuthorRepository();
    public Author GetAuthor (int authorId)
    {
        return authorRepository.GetAuthor(authorId);
    }
}

객체 매핑을 위한 템플릿 코드 작성 방지
데이터 전송 대상 (DTO) 과 필드 대상을 비추는 것이 자주 필요하지만, 반대로도 마찬가지다.아래에 제시된 코드 세션을 참고하십시오. 이것은 컨트롤러 방법 내부의 매핑 논리를 보여 줍니다.

public IActionResult GetAuthor(int authorId)
{
    var author = authorService.GetAuthor(authorId);
    var authorDTO = new AuthorDTO();
    authorDTO.AuthorId = author.AuthorId;
    authorDTO.FirstName = author.FirstName;
    authorDTO.LastName = author.LastName;
    authorDTO.JoiningDate = author.JoiningDate;
 }

컨트롤러에 이러한 매핑 논리를 작성해서는 안 된다. 왜냐하면 컨트롤러를 팽창시키고 추가 책임을 증가시키기 때문이다.매핑 논리를 작성하려면 AutoMapper와 같은 객체 매퍼 도구를 사용하여 템플릿 코드를 많이 작성하지 않도록 할 수 있습니다.
마지막으로, 맵 논리를 앞에서 만든 서비스 클래스로 옮겨야 합니다.AutoMapper가 호환되지 않는 두 종류의 Author와 Author DTO를 어떻게 비추는지 주의하십시오.

public class AuthorService
{
    private AuthorRepository authorRepository = new AuthorRepository();
    public AuthorDTO GetAuthor (int authorId)
    {
        var author = authorRepository.GetAuthor(authorId);
        return Mapper.Map(author);
    }
}

컨트롤러에서 업무 논리 코드를 작성하는 것을 피하다
컨트롤러에서 업무 논리를 작성하거나 검증 논리를 작성해서는 안 된다.컨트롤러는 요청 하나만 받고 다음 액션으로 넘어가야 합니다. 그 외에 다른 것은 없습니다.모든 업무 논리 코드는 다른 클래스로 옮겨야 합니다. (예를 들어 앞에서 만든 Author 서비스 클래스)컨트롤러에서 검증 논리를 작성하지 말고 요청 파이프에 검증기를 설정할 수 있는 몇 가지 방법이 있다.이것은 컨트롤러를 불필요하게 비대하게 만들고, 하지 말아야 할 임무를 맡게 할 것이다.
조합보다는 주입에 의존하는 걸 더 좋아해요.
컨트롤러에서 의존항 주입을 사용하여 의존항을 관리하는 것을 더 좋아해야 한다.의존 주입은 반전(IoC) 원칙을 제어하는 서브집합이다.외부에서 주입할 수 있는 의존항을 통해 내부 의존항을 삭제하는 데 사용됩니다.
의존 주입을 이용함으로써 대상의 실례화, 초기화 등에 신경 쓸 필요가 없다.필요한 유형의 실례를 되돌려 주는 공장을 만들 수 있고, 그 실례를 사용하기 위해 구조 함수 주입을 사용할 수 있다.다음 코드 세션에서는 IAuthor Service 유형의 인스턴스를 구조 함수를 사용하여 Author Controller에 주입하는 방법을 설명합니다.(IAuthorService가 AuthorService 클래스의 확장 인터페이스라고 가정합니다.)

public class AuthorController : Controller
{
    private IAuthorService authorService = new AuthorService();
    public AuthorController(IAuthorService authorService)
    {
       this.authorService = authorService;
    }
}

action 필터를 사용하여 중복 코드 제거
asp.netcore에서 action 필터를 사용하여 요청 파이프의 특정 점에서 맞춤형 코드를 실행합니다.예를 들어, 액션 필터를 사용하여 액션 방법을 실행하기 전과 후에 사용자 정의 코드를 실행할 수 있습니다.컨트롤러의 액션 방법에서 검증 논리를 삭제하고, 컨트롤러에서 검증 논리를 작성하지 않고 액션 필터에 쓸 수 있습니다.다음 코드 세션은 이 점을 어떻게 실현하는지 보여 줍니다.

[ValidateModelState]
[HttpPost]
public ActionResult Create(AuthorRequest request)
{
    AuthorService authorService = new AuthorService();
    authorService.Save(request);
    return RedirectToAction("Home");
}

컨트롤러에 여러 직책을 분배하면 컨트롤러가 바뀌는 여러 가지 원인이 있을 수 있다.따라서 이는 단일책임원칙을 위반하고 이 원칙의 규정류는 반드시 있고 단지 하나의 변경 이유가 있어야 한다.
텍스트 링크: https://www.infoworld.com/art...
저의 공식 계정에 관심을 가져 주십시오. 만약 당신이 좋아하는 외국어 기술 문장이 있다면, 공식 계정을 통해 저에게 추천해 주십시오.