Je suis actuellement aux prises avec la question de savoir si j'ai atteint un bon niveau de séparation, ou si j'ai raté quelque part, car je suis relativement nouveau pour apprendre le côté discipliné du développement ...Existe-t-il un moyen acceptable de séparer ces couches/dépendances?
Mon L'objectif quand j'ai commencé était de créer une couche agnostique de tout mécanisme de persistance - j'ai appelé cette API de données. J'ai ensuite implémenté ces interfaces en utilisant JDO, et j'ai appelé ce projet data-jdo. La couche logique parle idéalement seulement de data-api.
C'est le point où je ne suis pas sûr de ce qui est logique. La couche logique métier doit être invoquée d'une manière ou d'une autre, n'est-ce pas? Alors est-ce que l'on s'attend à ce que l'implémentation de l'API de données (data-jdo, ou autre chose en fonction de l'expérimentation) soit fournie (appropriée pour dire/injecter?) Par l'invocateur? Donc, le but serait (en grande partie pour l'expérience et non pour la productivité) de mettre en œuvre un paquet data-jpa qui pourrait être substitué à la place de data-jdo. Ainsi, la couche supérieure (un service Web, une méthode principale générique dans le cadre d'un outil, des tests unitaires, etc.) est celle qui choisit quelle implémentation utiliser. Dois-je utiliser un framework comme Spring pour me permettre de choisir quelle implémentation de mes API est utilisée, via XML?
Désolé si c'est un peu vague ... Je suppose que la question fondamentale est, à quel point le consommateur d'une API dépend, fournit, ou devenir jumelé avec, la mise en œuvre de cette API? Si la réponse est ou devrait être "jamais" alors qu'est-ce qui est utilisé pour s'assurer que tout est disponible au moment de l'exécution et comment le consommateur obtient-il une instance de ce que "l'API" décrit avec seulement des interfaces?