Question

Quelqu'un sait-il d'une mise en œuvre de flux paresseux .net? OIEau, je veux un pour créer une méthode comme ceci: 

public Stream MyMethod() {
    return new LazyStream(...whatever parameters..., delegate() {
        ... some callback code.
    });
}

et quand mon autre code appelle MyMethod () pour revenir récupérer le flux, il ne fonctionnera pas en fait un travail jusqu'à ce que quelqu'un essaie effectivement de lire du flux. La manière habituelle serait de faire MyMethod prendre le paramètre de flux comme paramètre, mais cela ne fonctionnera pas dans mon cas (je veux donner le flux retourné à un MVC FileStreamResult).

Pour expliquer davantage, ce que je suis à la recherche est de créer une série de transformations en couches, donc

Résultat de base de données set = (transformé en) => flux d'octets = (enchaîné à) => GZipStream = (passé à) = constructeur> FileStreamResult.

Le jeu de résultats peut être énorme (GB), donc je ne veux pas mettre en cache le résultat dans un MemoryStream, que je peux passer au constructeur GZipStream. Au contraire, je veux aller chercher du jeu de résultats que les données de demandes GZipStream.

Était-ce utile?

La solution

Cette réponse ( https://stackoverflow.com/a/22048857/1037948 ) Liens cet article sur la façon d'écrire votre propre classe de flux.

Pour citer la réponse:

  

Le producteur écrit des données sur le flux et le lit des consommateurs. Il y a un tampon au milieu afin que le producteur peut « écrire en avance » un peu. Vous pouvez définir la taille de la mémoire tampon.

Pour citer la source originale:

  

Vous pouvez penser à la ProducerConsumerStream comme une file d'attente qui a une interface de flux. En interne, il est mis en oeuvre comme un tampon circulaire. Deux indices garder une trace des points d'insertion et de retrait dans le tampon. Octets sont écrits à l'index tête, et retirées de l'indice de queue.

     

Si la tête s'enroule autour de la queue, le tampon est plein et le producteur doit attendre quelques octets à lire avant de pouvoir continuer à écrire. De même, si la queue rattrape la tête, le consommateur doit attendre octets à écrire avant de pouvoir continuer.

L'article décrit ensuite certains cas étranges lorsque les pointeurs enroulent autour, avec des exemples de code complet.

Autres conseils

La plupart des implémentations de flux sont, par nature, cours d'eau paresseux. En règle générale, un cours d'eau ne sera pas lire les informations de sa source jusqu'à ce qu'il soit demandé par l'utilisateur du flux (autre que certains extra « sur la lecture » pour permettre tamponnage de se produire, ce qui rend beaucoup plus rapide utilisation des cours d'eau).

Il serait assez facile de faire une mise en œuvre de flux qui ne pas lire jusqu'à ce que nécessaire en remplaçant

Dans votre classe Stream vous devez implémenter plusieurs méthodes de System.IO.Stream y compris la méthode Read.

Ce que vous faites dans cette méthode est à vous. Si vous choisissez d'appeler un délégué - c'est à vous aussi, et bien sûr vous pouvez passer ce délégué comme l'un des paramètres de votre constructeur. c'est au moins comment je le ferais.

Malheureusement, il faudra plus que la mise en oeuvre méthode lire, et votre délégué ne couvre pas d'autres méthodes nécessaires

Non affilié à StackOverflow
scroll top