Je construis un site Web à l'aide d'ASP.NET MVC4 pour télécharger / afficher des images et a trouvé quelques façons de faire afficher les images, principalement le ci-dessous -
2) strong> stocke l'image en tant que tableau d'octet et revenir Il utilise une action de contrôleur - p> 3) strong> stocke l'image en tant que tableau d'octets et reprenez-la dans la vue directement - P> xxx pré> Mes questions sont - p> 1) Quelle est la différence entre 1 et 2? em> p> 1 fournit directement le Chemin de fichier et 2 fournit une URL. Sont-ils la même chose à l'arrière-plan ou est une approche meilleure que l'autre? P> J'ai vérifié ici et il dit que - URL.Action construira le chemin d'accès à l'action, renvoyant une URL, et non les résultats de l'exécution de l'action. Donc, quand sont les résultats récupérés? P> 2) fait-il un impact sur la performance lorsque 3 est utilisé contre 1 ou 2? Em> p> 3) Quelle approche doit être utilisée lorsque les tailles d'image sont petites (moins de 1 Mo) ou grandes? Em> p> heureux si vous pouvez signaler à moi des liens qui peuvent également être utiles.
Merci. P> code - p> // modèle p> // contrôleur p> // vue (approche 2) p> // vue (Ceci est l'approche 3) p> @model IEnumerable<MyPhotoLibrary.Models.Photo>
@foreach (var item in Model) {
<tr>
<td>
<img src="@String.Format("data:image/jpg;base64,{0}", Convert.ToBase64String(item.Image))" />
</td>
</tr>
}
3 Réponses :
1) aura moins de traitement sur le côté serveur, car il y aura moins d'appels de fonction. Si vous souhaitez rendre la sortie de l'action - vous devez appeler la méthode HTML Helper HTML.RenderAction ou html.action plus sur le Différences ici
2) La différence entre 2 et 3 est que lorsque vous entrez la matrice d'octet directement, vous avez moins de voyages arrondis sur le serveur (looks DNS et tels), mais plus de données à télécharger dans une seule demande. Certains navigateurs, peuvent télécharger du contenu en parallèle (5-8 téléchargements parallèles par domaine), donc si vous utilisez 3, vous perdez en termes de vitesse de chargement de la page. Plus sur Paralel Téléchargements ici et Here
Et cela nous conduit à 3) Si vous avez de petites images, 3 est la voie à suivre, car le client demandera moins de ressources, et la page se charge plus rapidement, mais si vous avez de grandes images, vous devez utiliser 1.
Merci igarioshka. C'est très clair maintenant. Donc, pour de petites images, je peux utiliser 3 et pour les grandes images que je peux utiliser 1. Mais quand devrais-je préférer 2 sur 1?
@SidDharth Eh bien, vous utilisez 2 si vous avez un ensemble d'images et que vous souhaitez personnaliser globalement la manière dont ils sont rendus ou appliquer une logique personnalisée (validation de rôle de certaines sortes). 2 est fondamentalement une fonctionnalité ajoutée, comme vous pouvez implémenter les deux et 3 à travers un appel à une action
Je me suis regardé à moi-même récemment et je suis tombé sur le document de recherche Microsoft à BLOB ou Ne pas blob , qui compare les performances de stockage de fichiers (tels que des images) comme des données binaires dans une base de données à celle d'un système de fichiers classique.
Les résultats, résumés grossièrement:
Autres différences entre les options:
En outre, cela peut ne pas être pertinent pour votre situation spécifique, mais avoir les images chargées par un appel distinct vous permet de faire d'autres choses dans ces actions, comme de l'écriture pour déboguer des journaux ou de faire une autre maison de ménage dans les coulisses.
L'option +1 est meilleure que l'option 3 car la mise en cache d'image est difficile dans ce dernier, car le cache sera invalidé à chaque fois que la vue est modifiée (ou l'image elle-même). Base64 nécessiterait également un traitement supplémentaire
Ouais, la mise en cache mérite également de mentionner. Dans l'option 2, les navigateurs reconnaîtront qu'ils font une image et d'obtenir une image, ce qu'ils peuvent cacher et réutiliser plusieurs pages; En option 3, ils ne voient que des cordes massives de base64 qu'ils doivent traiter.
À propos de stocker des images dans un fichier ou une base de données, vous pouvez voir sqlskills.com / Blogs / Paul / SQL-Server-2008-FileStream-Performa NCE et comme vous avez dit recherche.microsoft.com/apps/pubs/?id=64525 et sur quel type d'impressions d'images de la vue Je suis d'accord avec vous sur l'approche 2 en raison de sa mise en cache et de sa charge en morceaux. Mais je ne sais pas comment pourrait avoir une incidence sur la performance par Ultra Count de frapper un serveur lorsqu'il n'avait pas de cache. Pouvez-vous vous informer absolument que?
Je n'ai pas le temps de tester la performance, mais je vous tiendrai quelques points.
Dans l'approche 1, vous n'allez vraiment pas uniquement sur le stockage et les performances du disque dur pour conserver les fichiers et sur vos capacités de serveur Web de la livraison de fichiers statiques.
Dans l'approche 2, vous générez la bytestream à chaque fois qu'il existe une demande ... Le stockage et la récupération sont dec pilés (HDD joue un rôle bien sûr), et vous ne pouvez pas tirer parti des capacités de mise en cache natives du serveur Web sans ajouter Certains code pertinent (qui peut être juste un attribut Dans l'approche 3, le client ne fait que rendre et vous envoyez l'image avec la page Web. Ici, la performance dépend vraiment du navigateur, mais gardez à l'esprit que cela prendra du temps pour recevoir la page entière si l'image est très grande.
Donc, je préférerais généralement l'approche 1, je n'ai que de stocker une voie d'image dans la base de données, puis je peux obtenir l'image du disque et laisser IIS faire la mise en cache, la livraison, l'optimisation, etc.
Il y a beaucoup de raisons valables à utiliser pour une approche 2, ce qui est principalement si vous avez une architecture de serveurs Web dirétributée, où l'approche 1 signifie que chaque serveur doit contenir une copie de l'image sur le disque dur, tout en ayant tout Dans un endroit dans la DB signifie que vous pouvez récupérer les iamges quand vous le souhaitez ... peut-être implémenter un peu de mise en cache pour éviter de frapper la DB dans chaque demande.
L'approche 3 n'est vraiment que pour une utilisation simple Petites images. Je dis un seul usage unique parce que vous ne souhaitez pas l'utiliser pour des icônes et des images utilisées tout autour, ils devraient rester statiques afin qu'ils puissent être mis en cache par le client.
espère que cela contribue à mieux prendre une meilleure décision.
Dans un scénario similaire à 2, avec une architecture de serveur Web multiple, dans un emploi passé, nous sommes allés pour une solution mixte: les images étaient sur la DB mais chaque serveur Web unique, sur la première demande après avoir frappé un 404 pour le image, téléchargerait l'image à partir de la base de données et chargerait le client de réessayer (qui est, d'une manière d'une manière très répande de mise en cache). de sortiecache mais il peut être plus complexe).