ServiceStack의 메시지 기반 접근 방식이 요청 DTO 설계를 어떻게 향상시킬 수 있습니까?

ServiceStack 요청 DTO 설계

WCF 및 WebAPI와 같은 웹 서비스 프레임워크는 API 호출을 특정 서명이 있는 일반적인 C# 메서드 호출로 생각하도록 권장합니다. 각 요청. 이와 대조적으로 ServiceStack은 전체 쿼리가 요청 메시지에 캡처되는 메시지 기반 접근 방식을 채택합니다. 이는 다음과 같은 이점을 제공합니다.

• 여러 RPC 호출을 단일 메시지 기반 서비스로 압축
• 호출 의미 및 응답 유형을 기반으로 서비스 그룹화

GetBooking 제한 리팩터링 서비스

이러한 개념을 GetBookingLimit 및 GetBookingLimits 서비스에 적용하려면 다음을 고려하세요.

• 서비스 운영과 유형 구별: 요청 DTO 유지(운영 ) 응답 DTO(데이터 유형).
• 일반 응답 반환: 이제 일반 ErrorResponse DTO를 통해 오류가 반환되므로 응답 DTO에서 ResponseStatus 속성을 제거합니다.
• 일관적인 명명법을 유지하세요. : 고유한 키 쿼리에 대해 Get을 예약하고 여러 항목을 반환하는 쿼리에 대해 찾기 또는 검색을 사용합니다.
• 자기 설명적 계약 목표: 요청 DTO를 쉽게 이해할 수 있도록 설명적인 속성 이름을 사용하세요.

리팩터링된 코드:

[Route("/bookinglimits/{Id}")]
public class GetBookingLimit : IReturn<BookingLimit>
{
    public int Id { get; set; }
}

[Route("/bookinglimits/search")]
public class FindBookingLimits : IReturn<List<BookingLimit>>
{
    public DateTime BookedAfter { get; set; }
}

[Authenticate]
public class BookingLimitService : AppServiceBase 
{ 
    public BookingLimit Get(GetBookingLimit request) 
    { 
        return new BookingLimit {...};
    }

    public List<BookingLimit> Get(FindBookingLimits request) 
    { 
        return new List<BookingLimit> {...};
    }
}

오류 처리 및 유효성 검사

• 오류는 C# 예외를 발생시키거나 Fluent 유효성 검사를 사용하여 처리할 수 있습니다.
• container.RegisterValidators(typeof(CreateBookingValidator).Assembly)를 사용하여 유효성 검사기를 등록하면 자동 유효성 검사가 필요하지 않습니다. 서비스에 침입성 코드를 추가합니다.
• 단일 사용을 고려하세요. StoreBooking은 생성 및 업데이트 모두에 대해 DTO를 요청합니다.

이러한 원칙을 따르면 ServiceStack의 메시지 기반 접근 방식을 사용하여 요청 DTO를 효과적으로 설계하고 구현할 수 있으며 코드 건조성과 명확성을 높일 수 있습니다.

위 내용은 ServiceStack의 메시지 기반 접근 방식이 요청 DTO 설계를 어떻게 향상시킬 수 있습니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!