Web Service Contract Design - Single-responsabilité

Question

Je suis curieux de voir comment la plupart des développeurs vont sur la conception des contrats à leurs services Web. Je suis tout à fait nouvelle à l'architecture de service et surtout nouveau pour WCF.

En bref, je voudrais savoir quel type d'objets que vous retournez dans vos opérations, et ne chaque opération dans votre service de retour le même objet?

Par exemple, considérons ce qui suit: À l'heure actuelle, tous les services que je crée Hériter d'un objet ServiceBase qui ressemble à:

public abstract class AppServiceBase<TDto> : DisposableObjectBase where TDto : IDto
{
    protected IAppRequest Request { get; set; }
    protected IAppResponse<TDto> Response { get; set; }
}

Response représente l'objet de retour qui compose comme quelque chose:

public interface IAppResponse<TDto> where TDto : IDto
{
    List<TDto> Data { get; }
    ValidationResults ValidationResults { get; }
    RequestStatus Status { get; }
}

Par conséquent, un service dérivé retournerait une réponse composée du même objet. Maintenant, au départ, je me sentais avec serait une bonne conception que cela oblige chaque service à être responsable d'un seul objet. Pour la plupart cela a fonctionné, mais que mes services se développent, je me suis trouvé en question cette conception.

Prenez ceci par exemple: Vous disposez d'un service de musique que vous écrivez et un de vos services serait « Albums ». Vous écrivez donc des opérations CRUD de base et ils reviennent à peu près tout une collection de AlbumDto.

Que faire si vous voulez écrire une opération qui retourne les types d'albums. (LP, à l'unité, EP, etc) Vous avez donc un objet AlbumTypesDto. Souhaitez-vous créer un nouveau service juste pour cet objet ou avoir votre retour de service Albums de nombreux objets différents?

Je peux imaginer un service complexe avec plusieurs types de retour variable pour être lourde et mauvaise conception, mais la rédaction d'un nouveau service entier pour ce qui peut-être, seulement une ou deux méthodes d'opération de service à overkill.

Que pensez-vous?

Answer 1

Il est une bonne idée de concevoir vos services autour de votre problème de domaine. En exposant un motif CRUD sur le service, essentiellement vous utilisez les services d'accès aux données. Le risque de c'est votre logique métier finira sur tout ce qui consomme votre service.

Service Vous devriez exposer les méthodes relavent au problème que vous essayez de résoudre (qui lâchement des modèles sur le fonctionnement sur l'interface utilisateur en général)

De là, vous verrez vos contrats de données commencent à adapter plus naturellement au problème que vous essayez de résoudre, au lieu de créer « taille unique » contrats.

Pour un bon départ, Google « Domain Driven Design » Mais il y a beaucoup de matériel de référence à ce sujet.