Comment concevoir des DTO de requête efficaces et cohérents dans ServiceStack ?

ServiceStack Request DTO Design

Dans les API RESTful, il est courant d'avoir plusieurs services servant différents objectifs. Même s’il est tentant de créer un service distinct pour chaque requête unique, cela peut conduire à une duplication inutile et à une architecture surchargée. ServiceStack promeut une approche différente, encourageant le regroupement des services en fonction de leur sémantique d'appel et de leurs types de réponse.

Distinguer les opérations de service des types

Les opérations de service (Request DTO) doivent capturer les actions uniques d'un service, tandis que les types DTO qu’ils renvoient représentent des entités ou des conteneurs de données. Les DTO de requête doivent utiliser des verbes (par exemple, « Obtenir », « Rechercher ») pour exprimer leurs actions, tandis que les types de DTO doivent utiliser des noms (par exemple, « Client », « Produit ») pour représenter leurs entités.

Retour Réponses génériques

Dans le cas d'une requête GET typique, ServiceStack ne nécessite pas de propriété ResponseStatus dans les DTO de réponse. Au lieu de cela, le DTO générique ErrorResponse sera lancé et sérialisé sur le client si une erreur se produit. Cela élimine le besoin de propriétés ResponseStatus explicites dans vos réponses.

Nomenclature cohérente

Pour améliorer la lisibilité et l'auto-description, il est recommandé d'utiliser une nomenclature cohérente dans vos contrats de service. Réservez le verbe "Get" aux services qui récupèrent un seul résultat basé sur un identifiant unique. Pour les services de recherche qui renvoient plusieurs résultats, utilisez les préfixes « Rechercher » ou « Rechercher ». De plus, fournissez des noms de propriété clairs et descriptifs qui indiquent leur objectif dans les DTO de la demande.

Services de limites de réservation refactorisés

Sur la base de ces principes, les services de limites de réservation refactorisés suivants sont proposés :

[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; }
}

Implémentation du service

L'implémentation du service peut être simplifiée en appliquant l'attribut [Authenticate] une fois sur le classe de service au lieu de chaque demande DTO. Le code suivant montre cette implémentation :

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

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

Gestion et validation des erreurs

La gestion et la validation des erreurs peuvent être personnalisées à l'aide des fonctionnalités Fluent Validation intégrées de ServiceStack. Au lieu d'injecter des validateurs dans le service, vous pouvez les enregistrer dans AppHost avec la ligne suivante :

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

Pour les opérations avec des effets secondaires (par exemple, POST/PUT), vous pouvez définir des validateurs tels que les suivants :

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

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!