Veuillez corriger mes torts. D'après ma lecture sur le sujet jusqu'à présent, il me semble que le stockage d'objets blob Azure et le service de fichiers offrent tous les deux la possibilité de stocker des fichiers et des dossiers (je comprends que les objets blob peuvent stocker n'importe quel objet binaire, mais tout objet sérialisé le flux binaire est juste un fichier à la fin de la journée) dans une structure hiérarchique qui imite un système de fichiers.
Seule l'API pour y accéder est légèrement différente en ce que le service de fichiers vous permet d'interroger la source à l'aide de fonctions de type E / S de fichier Win32, en plus d'utiliser l'API REST.
Pourquoi choisiriez-vous l'un plutôt que l'autre si vous vouliez que votre application stocke certains fichiers appartenant aux utilisateurs de votre application?
la source
Réponses:
Quelques éléments pour votre question:
Si vous développez une nouvelle application, tirez parti de l'API Azure native directement dans le stockage Blob.
Si vous portez une application existante qui doit partager des fichiers, utilisez Azure File Service.
Notez qu'il existe quelques fonctionnalités de protocole SMB que Azure File Service ne prend pas en charge .
la source
Quelques autres choses à considérer:
la source
Azure File Service est davantage ciblé sur la gestion des fichiers internes. Avec interne, je veux dire monter un répertoire sur une machine virtuelle dans le cloud ou sur site afin qu'il puisse être chargé dans votre back-end (protocole basé sur SMB).
Pour le partage de fichiers avec des utilisateurs finaux (Web ou applications), il est probablement plus judicieux d'utiliser le stockage d'objets blob, car cela simplifie le téléchargement via une URL et la sécurisation du téléchargement via les signatures d'accès partagé.
Cet article partage plus de détails sur la comparaison (en bas): https://blogs.msdn.microsoft.com/windowsazurestorage/2014/05/12/introducing-microsoft-azure-file-service/
la source