Question de conception de service WCF

Question

Est-ce que votre expérience du monde réel vous permet de définir un contrat de service avec une méthode qui acceptera un objet comme une forme de requête et retournera un autre objet à la suite de cette requête. Ce que je veux dire, c'est qu'au lieu d'avoir une méthode pour créer, supprimer, éditer et chercher des clients, ces activités seraient encapsulées dans DataContracts et ce que le service ferait après avoir reçu tel DataContract prendrait des mesures en conséquence. Mais l'interface de service serait plus simple:

interface ISomeService 
{ 
    IMessageResult Process(IMessageRequest msg); 
} 

Ainsi IMessageRequest aurait déposé le nom OperationType = OperationTypes.CreateCustomer et le reste des champs fournirait suffisamment d'informations pour le service qu'il pourrait créer un objet client ou un enregistrement dans la base de données ou tout . Et IMessageResult pourrait avoir un champ avec du code pour indiquer que le client a été créé ou non. Ce que j'essaie de réaliser par une telle conception est la possibilité de déléguer facilement IMessageRequest à d'autres services internes que le client ne connaîtrait même pas. Un autre avantage que je vois est que si nous devons ajouter une opération sur les clients nous fournissons seulement DataContract supplémentaire pour cette opération et ne devons rien changer du côté d'interface de service (je veux éviter ceci à tout prix, je ne veux pas dire nouveau opérations mais changement de l'interface de service :)

Alors, qu'en pensez-vous? Est-ce un bon moyen de gérer des processus métier complexes? Quels sont les pièges, quoi de mieux.

Si j'ai dupliqué un autre fil de discussion et qu'il y a des réponses à ma question, veuillez me fournir des liens car je ne les ai pas trouvés.

Answer 1

Réponse courte: oui, cela pourrait être une très bonne idée (et une que j'ai implémentée sous une forme ou une autre plusieurs fois).

Un bon point de départ pour ce type d'approche sont les messages par Davy Brion sur ce qu'il appelle le request/response layer. Il a consolidé ses idées initiales & pensées dans un projet OSS très utilisable appelé Agatha, que je propose sur un site client au moment où j'écris ceci.

Answer 2

C'est exactement ce que nous faisons ici où je travaille. Il fonctionne très bien et est facile à comprendre pour tous les développeurs, et très facile à câbler de nouvelles méthodes/classe/etc.