Le fournisseur de contenu est-il une implémentation de Repository Pattern?
Modèle de référentiel est défini par Hieatt et Rob Mee en tant que modèle de conception qui sert de intermédiaire entre les couches de mappage de domaine et de données à l'aide d'une interface de type collection permettant d'accéder aux objets de domaine.
Fondamentalement, il extrait un ou plusieurs périphériques d'E/S (nuage, disque, base de données, etc.) dans une interface semblable à une collection où vous pouvez lire, écrire, rechercher et supprimer des données .
Sur Android Clean Architecture de Fernando Cejas , toutes les données nécessaires à l'application proviennent de cette couche via une implémentation de référentiel (l'interface est dans la couche de domaine) qui utilise un modèle de référentiel avec une stratégie qui sélectionne différents sources de données en fonction de certaines conditions.
Cependant, comme l'a souligné le professeur Douglas Schmidt at cours de Coursera , fournisseur de contenu gère et facilite l'accès à un référentiel central de données vers une ou plusieurs applications
Dans le livre Programmation Android , les fournisseurs de contenu sont utilisés comme façade pour un service Web RESTful . Cette approche a été initialement présentée par Virgil Dobjanschi lors de Google I/O 2010 .
Ainsi, au lieu d'utiliser des fournisseurs de contenu pour accéder à la base de données locale SQLite , pourquoi ne pas l'utiliser comme modèle de référentiel lui-même?
Réponse courte: un fournisseur de contenu est une source de données et non un référentiel.
Le but de SQL-Database/Android-Contentproviders/Repositories est de créer/lire/mettre à jour/supprimer/trouver des données
Les référentiels fonctionnent généralement sur des classes Java spécifiques (telles que Client, Commande, Produit, ....) Tandis que les fournisseurs de bases de données SQL et Android-Content opèrent sur des tables, des lignes et des colonnes de bas niveau en tant que source de données .
Etant donné qu'une base de données SQL n'est pas un référentiel, un fournisseur de contenu Android-Content ne l'est pas non plus .
Mais vous pouvez implémenter un référentiel en utilisant un fournisseur de contenu sous-jacent
Je mentionnerai Dianne Hackborn (de l’équipe Android Framework) pour donner mon opinion.
Fournisseur de contenu
Enfin, ContentProvider est une installation assez spécialisée pour la publication de données d’une application vers d’autres lieux. Les gens les considèrent généralement comme une abstraction dans une base de données, car il existe de nombreuses API et un support intégré pour ce cas courant ... mais du point de vue de la conception du système, ce n'est pas leur but.
Pour le système, ils constituent un point d'entrée dans une application permettant de publier des éléments de données nommés, identifiés par un schéma d'URI. Ainsi, une application peut décider de la manière dont elle souhaite mapper les données qu'elle contient vers un espace de noms d'URI, en distribuant ces URI à d'autres entités qui peuvent à leur tour les utiliser pour accéder aux données. Cela permet au système de gérer certaines applications en particulier:
• La distribution d'un URI ne nécessite pas que l'application reste en cours d'exécution; elles peuvent donc être utilisées partout où l'application propriétaire est morte. C'est seulement au moment où quelqu'un dit au système, "hé, donnez-moi les données pour cet URI", faut-il s'assurer que l'application possédant ces données est en cours d'exécution, de sorte qu'elle puisse lui demander de récupérer et de restituer les données.
• Ces adresses URI constituent également un modèle de sécurité à la fine pointe de la technologie. Par exemple, une application peut placer l'URI d'une image qu'elle a dans le presse-papiers, mais laisser son fournisseur de contenu verrouillé afin que personne ne puisse y accéder librement. Lorsqu'une autre application extrait cet URI du presse-papiers, le système peut lui attribuer une "autorisation d'accès d'URI" temporaire lui permettant d'accéder aux données uniquement derrière cet URI, mais rien d'autre dans l'application.
Ce qui ne nous intéresse pas:
Peu importe la manière dont vous implémentez la gestion des données derrière un fournisseur de contenu; Si vous n'avez pas besoin de données structurées dans une base de données SQLite, n'utilisez pas SQLite. Par exemple, la classe d'assistance FileProvider est un moyen simple de rendre les fichiers bruts de votre application disponibles via un fournisseur de contenu.
De même, si vous ne publiez pas de données de votre application pour que d'autres puissent les utiliser, il n'est pas du tout nécessaire de recourir à un fournisseur de contenu. Il est vrai que, en raison des divers utilitaires construits autour des fournisseurs de contenu, cela peut être un moyen facile de placer des données dans une base de données SQLite et de les utiliser pour remplir des éléments d'interface utilisateur comme un ListView. Toutefois, si l'un de ces éléments rend plus difficile la tâche que vous tentez de réaliser, n'hésitez pas à ne pas l'utiliser et à utiliser un modèle de données plus approprié pour votre application.
Texte intégral ici: https://plus.google.com/+DianneHackborn/posts/FXCCYxepsDU
Bravo pour la question, c'est une belle observation :). IMHO, ce n'est pas une question de oui ou de non parce qu'elle est assez générale, comme le sont la plupart des sujets liés aux modèles de conception. La réponse dépend de quel contexte prenez-vous en compte:
Si vous avez une application qui repose entièrement sur la plate-forme, c'est-à-dire prenant en compte uniquement le contexte de l'écosystème Android, alors oui, ContentProvider IS et une implémentation du modèle de référentiel . L'argument ici est que le fournisseur de contenu a été conçu pour résoudre certains des mêmes problèmes que les modèles de référentiel visent à résoudre:
- Il fournit une abstraction sur la couche de données, de sorte que le code ne dépend pas nécessairement de l'environnement de stockage.
- Pas d'accès direct aux données de partout. Vous pouvez placer toutes vos requêtes SQL (ou autre) à un seul endroit. Lorsque j'ai implémenté ContentProvider en tant que noob, cela a été pour moi une révélation de la netteté de mon code et de la facilité avec laquelle je peux effectuer des modifications.
- Centralise les données et les partage entre plusieurs clients (autres applications, un widget de recherche comme vous le savez déjà) et fournit un mécanisme de sécurité des données
- Vous pouvez définitivement définir le comportement lié aux données (une solution consiste à utiliser ContentObserver)
- C'est un très bon moyen de vous forcer dès le début à organiser votre code en pensant aux tests unitaires/automatisés.
Si vous mettez tous ces éléments côte à côte avec les principes du modèle de référentiel, il existe de sérieuses similitudes. Tous ne sont pas satisfaits, mais les idées fondamentales sont les mêmes.
Désormais, dans le cas d’une application fonctionnant à plus grande échelle dans plusieurs environnements (c.-à-d. Web, mobile, PC), les exigences changent complètement. C’est une mauvaise idée, car tout le monde a suggéré de s’appuyer sur ContentProvider en tant que modèle de conception . Ce n'est pas nécessairement une mauvaise idée en soi, mais un modèle de conception doit être implémenté pour que les autres puissent comprendre votre code le plus rapidement possible. Vous voyez, même ici, tout le monde a suggéré une utilisation commune de ContentProvider: en tant que source de données, ou de toute façon quelque chose dépendant de la plate-forme. Donc, si vous forcez une implémentation sur un composant ayant un objectif connu, les choses peuvent devenir plutôt floues. Il est beaucoup plus agréable d'organiser votre code selon un modèle classique.
tl; dr; Si votre application est isolée sur votre appareil Android, vous pouvez certainement fusionner les deux concepts. Si votre application est utilisée à plus grande échelle, elle est plus propre sur plusieurs plates-formes, pour organiser votre code de manière classique.
Voilà une question intéressante. Je pense que ma première réponse sera non, le fournisseur de contenu n'est pas une implémentation du modèle de référentiel.
Comme vous l'avez mentionné, le modèle de référentiel est destiné à séparer la logique métier (domaine) de la couche de données. Cette approche vous permet de créer des tests unitaires pour votre logique métier (le domaine ne doit donc pas dépendre d'Android). En utilisant un fournisseur de contenu, vous devez avoir une sorte d’objets Android dans votre domaine.
Vous pouvez imaginer un moyen de masquer la logique du fournisseur de contenu derrière une interface, mais vous perdrez de nombreux éléments sympas qu'un fournisseur de contenu vous permet de faire.
Si vous êtes intéressé par l'architecture Android, je vous recommande de jeter un coup d'œil à ce projet Github Android Clean Architecture . Vous trouverez un moyen agréable de séparer votre présentation, votre domaine et votre couche de données. La communication entre le domaine et les données s'effectue à l'aide d'un modèle de référentiel.
J'espère que cela aidera!
IMHO, il est préférable de considérer un fournisseur de contenu comme source de données, bien que les données puissent être stockées de plusieurs manières (base de données SQLite, fichiers, ...), afin de conserver une certaine indépendance entre l'architecture et le framework Android.
Un référentiel Google fournit des exemples d'architecture. L'un d'eux contient un exemple d'architecture avec un fournisseur de contenu et un référentiel:
googlesamples/Android-architecture/todo-mvp-contentproviders
Extraits sélectionnés:
Vous pouvez ensuite utiliser des fournisseurs de contenu pour prendre en charge des fonctionnalités supplémentaires qui ne sont pas couvertes par cet exemple, offrant ainsi les avantages suivants:
- Vous permet de partager en toute sécurité les données stockées dans votre application avec d'autres applications.
- Ajouter un support pour les recherches personnalisées dans votre application.
- Développez des widgets permettant d'accéder aux données de votre application.
Le fournisseur de contenu est un composant Android, l'odeur ne sera pas bonne si vous mélangez le concept de référentiel avec ce composant, cela crée une dépendance de blocage à votre application.
Le problème lié à l'utilisation de ContentProviders en tant que référentiel est que vous ajoutez une dépendance dans votre modèle à Android Framework. L'utilisation des modèles de référentiel vous permet de simuler, tester et remplacer facilement des implémentations.
L'approche appropriée consisterait à masquer ContentProvider sous une interface et à permettre au modèle d'accéder aux données via cette interface. De cette façon, votre code est découplé de la plate-forme.
En gros, ContentProvider est la source d’E/S que vous souhaitez extraire.