Conception d'API et modèle DAO

Question

Je dois créer une API pour une application (disons un gestionnaire de bibliothèque). Comme beaucoup d'applications typiques, elle est faite au-dessus d'un outil ORM qui fait que les POJOs sont persistés dans les dbms. Je dois maintenant créer une API pour que d'autres développeurs puissent l'utiliser comme un JAR. Disons que nous voulons que les utilisateurs ajoutent des livres à la bibliothèque. J'ai de nombreuses questions sur la meilleure façon de le concevoir.

1) Est-ce une bonne idée d'avoir des classes de type DAO pour les POJO ?
BookManager { create(...) delete(Book book); List<Book> getAll(); ... }

2) Exposer des objets :

a) Dois-je exposer les POJO de l'application à la couche API ? Ces POJO ont une logique d'application qui ne doit pas être exposée et une autre logique que je veux exposer. Par exemple, je veux exposer book.getPages() mais pas book.deletePage(int pageNo).

b) Créer des objets dupliqués spécialement pour la couche API. Seule l'interface sera exposée.

c) Ne pas exposer les Objets du tout. L'API est utilisée en utilisant des paramètres. Par exemple

BookManager { create(String name, int price); delete(String name); List<Pair<String, Integer>> getAll(); ... }

Cela signifie un point d'accès unique au système. Si une opération doit être effectuée sur le POJO, elle sera appelée depuis BookManager. Par exemple, ClockManager.start(String clockName). Cela donne également de la flexibilité, comme le fait d'avoir des méthodes comme startAll() dans ClockManager.

3) Enfin, le BookManager doit-il contenir une méthode pour update(), ou doit-elle être présente dans le Book lui-même ? update signifie enregistrer la configuration dans la base de données. Ce qui est plus logique :

Book book = bookManager.create("API Design"); book.setPrice(); book.update();

Ou,

Book book = bookManager.create("API Design"); book.setPrice(); bookManager.update(book);

Merci d'avance,
Aman

Answer 1

Je ne peux m'empêcher de penser que certaines des questions soulevées viennent du fait que votre POJO contient une fonctionnalité plus proche de quelque chose comme ActiveRecord. Par exemple, le livre contenant la méthode ".GetPages()". S'il s'agissait d'un vrai POJO, les pages seraient déjà chargées (ou une référence cachée à la DAO pour qu'elles puissent être chargées paresseusement). De même, lorsque vous supprimez une page, vous n'avez pas besoin de connaître le DAO à ce moment-là. Vous supprimez la page du livre, puis vous sauvegardez le livre dans le BookDAO. Je ne recommanderais pas non plus l'approche du chargement paresseux de tout POJO que vous exposez via votre API.

Pour essayer de répondre exactement à vos questions :

1. Quelque chose comme ça, je pense que oui.

2. Il est évident que l'option (c) est la plus susceptible d'être utilisée par tous les consommateurs. Si vous appelez votre API et que vous souhaitez supprimer un livre, voulez-vous vraiment obtenir le livre en premier lieu pour le transmettre, ou voulez-vous simplement transmettre l'ID ou le nom (que vous avez peut-être déjà).

3. BookManager devrait avoir Update(Book book book). Si vous mettez Update sur Book, vous passez de POJO à une fonctionnalité de type ActiveRecord. L'un ou l'autre est acceptable dans la bonne situation, mais un hybride est toujours déroutant.

Note : pour (3), un type d'enregistrement actif complet serait

Book book = Book.Load("API Design"); book.SetPrice(45); book.Update()

Answer 2

Réponse courte :

1. Pas nécessairement. Je ne laisserais pas l'outil ORM que j'utilise dicter ma conception. Vous n'avez pas dit quel outil vous utilisez, mais les bons outils sont très flexibles et peuvent faire persister presque n'importe quelle conception POJO.

2. Choisissez b). N'exposez pas plus que ce dont vous avez besoin, mais il est préférable d'exposer des objets que d'introduire le type d'indirection utilisé en c).

3) La première option est meilleure.

En fait, je ne suis pas aussi sûr de vous donner le bon conseil que j'en ai l'air. La raison en est qu'il y a de nombreux compromis à prendre en compte. C'est le meilleur conseil que je puisse vous donner en fonction de ce que je sais de votre projet...

Je gère un site web sur la conception des API :

http://theamiableapi.com/

Vous pouvez également lire un ou deux livres. Regardez sous Ressources dans le menu. Celui de Joshua Bloch ou peut-être celui de Jaroslav Tulach.

Ferenc