Différentes façons d'afficher des images dans ASP.NET MVC et lors de l'utilisation de l'approche
Je suis en construction d'un site web à l'aide de ASP.NET MVC4 à télécharger/afficher des images et trouvé quelques façons de faire pour afficher des images, principalement à la ci-dessous -
1) Stocker l'image dans un fichier local sur le serveur et d'utiliser un chemin relatif pour l'afficher sur la page.
//ImageFile is a property which holds a path to the image in the model
<img src="@item.ImageFile" />
When the page is rendered, this becomes a path like - <img src="/Content/Images/Jellyfish.jpg" /> 2) Stocker l'image comme un tableau d'octets et de restauration à l'aide d'un contrôleur de l'action
//Use a controller action (GetImg) to get the URL of the image
<img src="@Url.Action("GetImg", "ViewPhotos", new { id = item.ID })" alt="Image" />
When the page is rendered, this becomes a path like - <img src="/ViewPhotos/GetImg/4" alt="Image" /> 3) Stocker l'image comme un tableau d'octets et de restauration dans la vue directement
//Directly re-construct the image in the view from the byte array (Image property of the model)
<img src="@String.Format("data:image/jpg;base64,{0}", Convert.ToBase64String(item.Image))" />
When the page is rendered, this becomes a path like - <img src="data:image/jpg;base64,/9j/4AAQSkZJRgABAgEA....<long string> .../>Mes questions sont -
1) Quelle est la différence entre le 1 et le 2 ?
1 fournit directement le chemin d'accès au fichier et 2 fournit une URL. Sont-ils les mêmes dans l'arrière-plan ou une méthode meilleure que l'autre?
J'ai vérifié ici et il dit que c' - Url.Action va construire le chemin de l'action, de retour d'une url, et non les résultats de l'exécution de l'action. Alors, à quel moment les résultats sont-ils récupérés?
2) - T-il fait un impact sur les performances lors de la 3, est utilisée contre 1 ou 2?
3) l'approche Qui doit être utilisé lorsque les images sont de petites tailles (moins de 1 mo) ou grande ?
Heureux si vous pouvez pointer vers moi tous les liens qui peuvent être utiles.
Merci.
Code -
//Modèle
public class Photo
{
public int ID { get; set; }
public string ImageFile { get; set; }
public byte[] Image { get; set; }
public string Caption { get; set; }
}//Contrôleur
public FileContentResult GetImg(int id)
{
byte[] byteArray = db.Photos.Find(id).Image;
if (byteArray != null)
{
return new FileContentResult(byteArray, "image/jpeg");
}
else
{
return null;
}
}//Afficher (approche 2)
@model IEnumerable<MyPhotoLibrary.Models.Photo>
@foreach (var item in Model) {
<tr>
<td>
<img src="@Url.Action("GetImg", "ViewPhotos", new { id = item.ID })" alt="Image" />
</td>
</tr>
}//Afficher (c'est l'approche 3)
@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>
}OriginalL'auteur siddharth | 2013-05-31
Vous devez vous connecter pour publier un commentaire.
J'ai regardé ce moi-même récemment, et suis tombé sur le Microsoft document de recherche De BLOB Ou De ne Pas GOUTTE, qui compare les performances de stockage de fichiers (comme des images) en tant que données binaires dans une base de données à un système de fichiers classique.
Les résultats, à peu près résumé:
D'autres différences entre les options:
Option 1 nécessite que l'application pour avoir les autorisations de lecture sur le dossier sur lequel les images sont dans l', et si les images sont en cours de téléchargement ou modifiés par les utilisateurs, alors l'application a besoin d'autorisations en écriture sur ce dossier. Cela peut être difficile si vous êtes en hébergement mutualisé (en particulier sur les bas prix ou gratuit plans d'hébergement) ou si votre administrateur de système est particulièrement paranoïaque.
Option 2 nécessite plus d'appels à partir du serveur vers le client pour obtenir toutes les données, cela peut sembler être une mauvaise chose, mais il ne briser le pageload en morceaux qui pourraient réellement aider à la page (sans les images) charge sur le premier appel, puis les images seront demandés séparément, Si l'un d'entre eux prend un certain temps, ou a une sorte d'erreur, puis le reste de la page ne devraient pas être touchés, ce qui est agréable. Comme jgauffin souligné dans les commentaires, cette option vous permet de configurer la mise en cache pour les images, afin que les navigateurs peuvent économiser de la bande passante en ne téléchargeant à nouveau quand ils ont changé.
Option 3 exige que le client charge le tout dans un, ce qui peut prendre un certain temps. Il change également de la transformation du tableau d'octets sur le client, qui peut être un problème de faible puissance à des clients comme les smartphones ou les bas de gamme de netbooks. Si vos images sont grandes, il peut être préférable d'utiliser le serveur de la puissance du PROCESSEUR pour en fait de gérer la conversion de tableau d'octets dans un fichier image. Comme jgauffin notes dans les commentaires, cela ne joue pas bien avec le cache - si une partie de l'affichage de modifications HTML, les navigateurs devront télécharger à nouveau les images
Aussi, cela peut ne pas être pertinents à votre situation spécifique, mais d'avoir les images chargées par un appel séparé vous permet de faire d'autres choses dans ces actions, comme la rédaction de journaux de débogage ou de faire quelque autre ménage derrière les coulisses.
Ouais, la mise en cache est également intéressant de mentionner. Dans l'option 2, navigateurs reconnaissent que ils font un OBTENIR et d'obtenir une image, qu'ils peuvent mettre en cache et réutiliser sur plusieurs pages; option 3-ils ne voient massive base64 chaînes dont ils ont à traiter.
À propos de stocker des images dans le fichier de base de données ou vous pouvez voir sqlskills.com/blogs/paul/sql-server-2008-filestream-performance et comme vous l'avez dit research.microsoft.com/apps/pubs/?id=64525 et sur le type de l'appel des images de vue je suis d'accord avec vous sur l'approche 2 en raison de son cache et de la charge en morceaux. mais je ne sais pas comment pourrait affecter les performances de ultra comte de frapper serveur quand il n'avait pas de cache. Pouvez-vous absolument vous informer que?
OriginalL'auteur anaximander
1) aura moins de traitement sur le côté serveur, car il y aura moins d'appels de fonction. si vous voulez rendre la sortie de l'action, vous devez appeler la méthode d'assistance HTML Html.RenderAction ou Html.De l'Action sur le les différences ici
2) la différence entre le 2 et le 3, c'est que lorsque vous entrez le tableau d'octets directement, vous avez moins d'allers-retours vers le serveur DNS (look-up), mais plus de données à télécharger en une seule requête. Certains navigateurs peuvent télécharger du contenu en parallèle (5-8 téléchargements en parallèle par domaine), donc si vous utilisez 3, vous perdez en termes de vitesse de chargement des pages. plus sur paralel téléchargements ici et ici
et cela nous amène à 3) si vous avez des images de petite taille, 3 est le chemin à parcourir, que le client demande moins de ressources, et le chargement de la page plus rapidement, mais si vous avez des images de grande taille, vous devez utiliser 1.
eh bien, vous utilisez 2 si vous disposez d'un ensemble d'images et que vous voulez à l'échelle mondiale personnaliser la façon dont ils sont rendus, ou appliquer une logique personnalisée (rôle de validation de quelque sorte). 2 est en fait un plus de fonctionnalités, comme vous l'avez peut mettre en œuvre à la fois 1 et 3 par le biais d'un appel à l'action
OriginalL'auteur Igarioshka
Je n'ai pas le temps de tester les performances, mais je vous tiendrai au courant d'un couple de points.
Dans l'approche 1, vous êtes en effet en s'appuyant uniquement sur le HDD de stockage et des performances pour les fichiers et sur votre serveur web, capacités de livraison de fichiers statiques.
Dans l'approche 2, de la production de la bytestream, à chaque fois, il y a une demande... de stockage et de récupération est DB (disque dur joue un rôle, bien sûr), et vous ne pouvez pas tirer parti de la maternelle capacités de mise en cache du serveur web sans l'ajout de certains pertinentes du code (ce qui est peut-être juste un attribut
OutputCachemais il peut être plus complexe).Dans l'approche 3, le client est juste le rendu et vous envoyez l'image avec la page web. Ici, la performance dépend vraiment sur le navigateur, mais gardez à l'esprit que cela prendra un certain temps pour recevoir l'ensemble de la page si l'image est très grande.
Donc, je préfère généralement s'approche de 1, je n'ai qu'à stocker le chemin de l'image dans la base de données et puis je peux obtenir l'image à partir du disque et laissez-IIS effectuer la mise en cache, la livraison, l'optimisation etc.
Il y a beaucoup de raisons valables à l'aller pour la méthode 2, surtout si vous avez un ditributed serveurs web de l'architecture, où 1 signifie que chaque serveur doit contenir une copie de l'image sur le disque dur, tout en ayant tout en un seul endroit dans la DB signifie que vous pouvez récupérer les iamges quand vous voulez... Peut-être appliquer un peu de mise en cache pour éviter de heurter la DB dans chaque demande.
Approche 3 est vraiment uniquement pour les utiliser de petites images. Je dis à usage unique parce que vous ne souhaitez pas l'utiliser pour les icônes et les images utilisés tout autour, ceux-ci devraient rester statique, de sorte qu'ils peuvent être mis en cache par le client.
Espère que permet de faire une meilleure décision.
Dans un scénario similaire à 2, avec un multiple serveur web de l'architecture, dans un passé de travail, nous sommes allés pour une solution mixte: les images ont été sur la DB, mais chaque serveur web unique, sur la première demande, après avoir atteint un 404 pour l'image, seraient télécharger une image à partir de la DB et de demander au client de réessayer (qui est, d'une certaine façon, très brut de mise en œuvre de la mise en cache).
OriginalL'auteur Tallmaris