Wie entwerfe ich effiziente und konsistente Anforderungs-DTOs in ServiceStack?

ServiceStack Request DTO Design

In RESTful APIs ist es üblich, dass mehrere Dienste unterschiedliche Zwecke erfüllen. Obwohl es verlockend ist, für jede einzelne Anfrage einen separaten Dienst zu erstellen, kann dies zu unnötiger Duplizierung und einer aufgeblähten Architektur führen. ServiceStack fördert einen anderen Ansatz und fördert die Gruppierung von Diensten basierend auf ihrer Anrufsemantik und Antworttypen.

Unterscheidung von Dienstvorgängen und -typen

Dienstvorgänge (Anforderungs-DTOs) sollten die einzigartigen Aktionen eines erfassen Dienst, während die von ihnen zurückgegebenen DTO-Typen Entitäten oder Datencontainer darstellen. Anforderungs-DTOs sollten Verben (z. B. „Get“, „Find“) verwenden, um ihre Aktionen zu übermitteln, während DTO-Typen Substantive (z. B. „Customer“, „Product“) verwenden sollten, um ihre Entitäten darzustellen.

Returning Generische Antworten

Im Fall einer typischen GET-Anfrage benötigt ServiceStack keine ResponseStatus-Eigenschaft in Antwort-DTOs. Stattdessen wird das generische ErrorResponse-DTO ausgelöst und auf dem Client serialisiert, wenn ein Fehler auftritt. Dadurch entfällt die Notwendigkeit expliziter ResponseStatus-Eigenschaften in Ihren Antworten.

Konsistente Nomenklatur

Um die Lesbarkeit und Selbstbeschreibung zu verbessern, wird empfohlen, in Ihren Serviceverträgen eine konsistente Nomenklatur zu verwenden. Reservieren Sie das Verb „Get“ für Dienste, die ein einzelnes Ergebnis basierend auf einer eindeutigen Kennung abrufen. Für Suchdienste, die mehrere Ergebnisse zurückgeben, verwenden Sie die Präfixe „Suchen“ oder „Suchen“. Geben Sie außerdem in den Anforderungs-DTOs klare und beschreibende Eigenschaftsnamen an, die ihren Zweck angeben.

Überarbeitete Buchungslimit-Dienste

Basierend auf diesen Grundsätzen werden die folgenden überarbeiteten Buchungslimit-Dienste vorgeschlagen:

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

public class BookingLimit
{
    public int Id { get; set; }
    public int ShiftId { get; set; }
    public DateTime StartDate { get; set; }
    public DateTime EndDate { get; set; }
    public int Limit { get; set; }
}

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

Service-Implementierung

Die Service-Implementierung kann durch Anwenden des [Authentifizieren]-Attributs vereinfacht werden einmal für die Serviceklasse statt für jedes Anforderungs-DTO. Der folgende Code zeigt diese Implementierung:

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

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

Fehlerbehandlung und Validierung

Fehlerbehandlung und Validierung können mithilfe der integrierten Fluent Validation-Funktionen von ServiceStack angepasst werden. Anstatt Validatoren in den Dienst einzufügen, können Sie sie im AppHost mit der folgenden Zeile registrieren:

container.RegisterValidators(typeof(CreateBookingValidator).Assembly);

Für Vorgänge mit Nebenwirkungen (z. B. POST/PUT) können Sie Validatoren wie die folgenden definieren :

public class CreateBookingValidator : AbstractValidator<CreateBooking>
{
    public CreateBookingValidator()
    {
        RuleFor(r => r.StartDate).NotEmpty();
        RuleFor(r => r.ShiftId).GreaterThan(0);
        RuleFor(r => r.Limit).GreaterThan(0);
    }
}

Das obige ist der detaillierte Inhalt vonWie entwerfe ich effiziente und konsistente Anforderungs-DTOs in ServiceStack?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!