Quels sont les avantages et les inconvénients de l'utilisation d'un calque Data Services?

Question

Il s'agit d'une discussion qui semble réapparaître régulièrement dans le monde SOA. Je l'ai entendu dès 95, mais cela faisait probablement déjà l'objet de discussions bien avant. J'ai certainement mes propres opinions à ce sujet, mais j'aimerais entendre de bons et solides arguments pour avoir un Data Services Layer, et de même pour les arguments contre l'existence d'un Data Services Layer.

Quelle valeur ajoute-t-elle à une architecture de système? Quels sont les pièges inhérents? Quels sont les anti-modèles courants?

Les liens vers des articles sont définitivement acceptables. Pour éviter toute confusion, this article décrit le type de couche de service de données dont je parle. Essentiellement, une couche mince au-dessus de la base de données qui fournit un accès SOAP aux données et n'inclut aucune logique métier.

Answer 1

Les services de données sont plutôt axés sur les données, pour les projets sans logique qui font toujours crud. Par exemple, il peut convenir si vous avez un service de notation ou un service de propriétés, vous ferez juste le crud à lui. Si le domaine qui implique ce DDBB est complexe, avec une logique complexe, vous devrez gérer cette logique jusqu'à ce service (peut-être dans une orchestration), donc vous diviserez la logique en plusieurs services. Dans ce cas, je pense qu'il vaut mieux utiliser un service unique plus épais (DAL, BLL et SIL) qui gère ce domaine et n'expose qu'une seule interface. En fin de compte, c'est un autre outil, en fonction du problème.