Expondo Recursos Embutidos em Assemblies - OWIN

by Israel Aece 16. August 2014 11:12

No último artigo falei sobre a possibiliade que o OWIN permite ao estender o sistema de arquivos, o que nos deixa buscar os arquivos requisitados em um local diferente do convencional, tal como uma base de dados, assim como foi mostrado lá. A ideia deste pequeno post é apenas mencionar que também existe um outro sistema de arquivos já nativo no OWIN.

Trata-se do EmbeddedResourceFileSystem, e como o próprio nome sugere, é responsável por resolver as requisições procurando pelo recurso solicitado em arquivos que estão embutidos em um determinado assembly. Geralmente utilizamos esta técnica para facilitar o deployment e não correr nenhum risco de apagarem o arquivo que é útil para a aplicação funcionar. O trecho de código abaixo ilustra como fazer uso deste sistema de arquivos:

public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        app.UseStaticFiles(new StaticFileOptions()
        {
            FileSystem = new EmbeddedResourceFileSystem()
        });
    }
}

Esta classe permite especificarmos o assembly que armazena os recursos e também o namespace padrão, já que todo recurso, para ser acessado, é necessário especificar o caminho completo até ele, e não trata-se de caminho físico. Ao utilizar o construtor padrão desta classe (sem parâmetros), a fonte de pesquisa é o assembly chamador e o namespace padrão é vazio. Há outros overloads do construtor que nos permite especificar um assembly e namespace diferente, possibilitando a expor recursos que estão embutidos em um assembly diferente daquele que é responsável pelo host do OWIN.

Na imagem abaixo podemos perceber que o arquivo Pagina.htm está dentro do diretório Recursos. Antes de realizarmos os testes, é necessário marcar a propriedade Build Action do arquivo como Embedded Resource e assim tornar o arquivo parte do assembly.

Para acessar o recurso no navegador, basta digitarmos o seguinte endereço: http://localhost:1981/Teste.Recursos.Pagina.htm. Intuitivo ou não, o caracter separador é o ponto, pois ao embutir o recurso no assembly, o acesso ao mesmo se dá pelo full-name, assim como foi falado anteriormente. Se desejar, pode optar por implementar a interface IFileSystem e customizar para alterar o ponto pela barra e tornar o acesso mais próximo da realidade da Web.

Tags: , , ,

OWIN

Requisições para o Banco de Dados - OWIN

by Israel Aece 12. August 2014 23:45

Em geral, um projeto Web serve páginas HTML e que com o auxílio de alguma tecnologia como PHP ou ASP.NET, tornam estas páginas dinâmicas. Além de HTML, projetos Web também possuem outros tipos de arquivos que complementam estas aplicações, tais como CSS, Javascripts, Imagens, etc.

Além disso, dependendo do tipo de projeto que estamos trabalhando, há outros tipos de arquivos que a aplicação aceita que os usuários enviem ou arquivos que a própria aplicação gera e disponibiliza a seus usuários. Esses arquivos são, na maioria das vezes, armazenados no disco, em um diretório específico para não misturar com os arquivos que fazem parte da aplicação em si, e não são referentes ao conteúdo que ela manipula.

Apesar do armazenamento em disco ser o mais comum, é possível ver empresas que optam por armazenar o conteúdo do arquivo no banco de dados, onde o backup é um de seus principais benefícios, pois tudo o que a aplicação precisa para trabalhar está ali. Só que quando optamos por inserir e manter os arquivos no banco de dados, a forma de acesso muda bastante. Em tempos de ASP.NET Web Forms, uma opção seria criar um handler (ASHX) para recuperar o arquivo solicitado pelo cliente, que informava na querystring o arquivo que ele estava querendo acessar; este handler, por sua vez, realizava a busca na base e escrevia no stream de saída os bytes do arquivo.

Dependendo da tecnologia que estamos utilizando, podemos adotar diferentes técnicas de acesso à este tipo de conteúdo. Se estivermos utilizando o OWIN, é possível criar algo mais simples e "flat" para expor os arquivos que estão salvos em uma base de dados. Como sabemos, o OWIN é um servidor Web bastante leve e estensível, e uma das opções que temos disponíveis, é justamente apontar de onde e como extrair os recursos (arquivos) que estão sendo solicitados ao servidor.

A ideia é criar um mecanismo que busque os arquivos solicitados em uma base de dados, utilizando o OWIN para criar um servidor Web customizado, que hospedaremos em uma aplicação de linha de comando (Console). O primeiro passo depois do projeto criado, é instalar os dois pacotes abaixo (através do Nuget):

Install-Package Microsoft.Owin.SelfHost
Install-Package Microsoft.Owin.StaticFiles

Antes de começarmos a programar, precisamos definir a estrutura da base de dados que irá acomodar os arquivos. Para manter a simplicidade, vamos nos conter em apenas uma tabela chamada File com três colunas: Name, Date e Content. A imagem abaixo ilustra os arquivos que adicionei manualmente para o exemplo. Quero chamar a atenção para três arquivos: Pagina.htm, Styles.css e CD.jpg. Como vocês já devem estar percebendo, a página HTML é que menciona o CSS para formatar a mesma e a imagem é colocada em um atributo <img /> nesta mesma página.



O próximo passo é customizar o nosso sistema de arquivos, e para isso, o OWIN fornece duas interfaces: IFileSystem e IFileInfo. A primeira define a estrutura que nosso "repositório" de arquivos deverá ter, enquanto a segunda determina quais os atributos (propriedades) nossos arquivos devem ter. A implementação da classe que representará o arquivo é simples, pois os dados já estão armazenados em nossa base, e utilizaremos o contrutor para que as informações sejam repassadas para a classe:

public class DatabaseFileInfo : IFileInfo
{
    private readonly byte[] content;

    internal DatabaseFileInfo(string name, DateTime date, byte[] content)
    {
        this.content = content;

        this.Name = name;
        this.LastModified = date;
        this.Length = this.content.Length;
    }

    public Stream CreateReadStream()
    {
        return new MemoryStream(this.content);
    }

    public long Length { get; private set; }

    public string Name { get; private set; }

    //outras propriedades
}

O próximo passo é implementar o sistema de arquivos, utilizando a interface IFileSystem. Aqui devemos procurar pelo arquivo solicitado, e se encontrado, retornar o mesmo através do parâmetro de saída fileInfo, que deve ser instanciado com a classe que criamos acima. É importante notar que passamos a string de conexão com a base de dados, e no interior do método TryGetFileInfo fazemos a busca e utilizamos o DataReader para extrair as informações e instanciar a classe DatabaseFileInfo passando as informações inerentes ao arquivo solicitado.

public class DatabaseFileSystem : IFileSystem
{
    private readonly string connectionString;

    public DatabaseFileSystem(string connectionString)
    {
        this.connectionString = connectionString;
    }

    public bool TryGetFileInfo(string subpath, out IFileInfo fileInfo)
    {
        fileInfo = null;

        using (var conn = new SqlConnection(this.connectionString))
        {
            using (var cmd = new SqlCommand("SELECT Name, Date, Content FROM [File] WHERE Name = @Name", conn))
            {
                cmd.Parameters.AddWithValue("@Name", subpath.Replace("/", ""));
                conn.Open();

                using (var dr = cmd.ExecuteReader(CommandBehavior.CloseConnection))
                    if (dr.Read())
                        fileInfo = 
                            new DatabaseFileInfo(dr.GetString(0), dr.GetDateTime(1), (byte[])dr.GetValue(2));
            }
        }

        return fileInfo != null;
    }
}

As classes que criamos até agora não são suficientes para tudo funcione, pois precisamos acoplar à execução, e utilizaremos o modelo de configuração do OWIN para incluir este - novo - sistema de arquivos. Ao instalar os pacotes que foram mencionados acima, há alguns métodos de estensão que nos dão a chance de realizar estas configurações, e para ser mais preciso, me refiro ao método UseStaticFiles, que através da classe StaticFileOptions, é possível apontar a classe DatabaseFileSystem que acabamos de criar, para que o OWIN recorra à ela sempre que um arquivo for solicitado.

public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        app.UseStaticFiles(new StaticFileOptions()
        {
            FileSystem = new DatabaseFileSystem("Data Source=.;Initial Catalog=DB;Integrated Security=True")
        });
    }
}

Quando um arquivo não for encontrado, automaticamente o cliente receberá o erro 404 (NotFound). Já quando o arquivo for encontrado, o mesmo será renderizado diretamente no navegador, assim como podemos visualizar nos exemplos abaixo:

Tags: , ,

Data | OWIN

Renderizando uma View em PDF

by Israel Aece 11. August 2014 23:19

É muito comum precisarmos gerar PDFs em nossas aplicações, e muitas vezes, estes PDFs são referentes à conteúdos baseados em HTML. Há uma porção de componentes que são capazes de receber uma string como conteúdo HTML e gerar o respectivo PDF. Entre estes componentes, temos o Evo PDF, que possui uma API de fácil utilização. Para fazer uso do mesmo, basta utilizar o Nuget para instalar na aplicação que deseja fazer uso:

PM> Install-Package EvoPDF

O conteúdo a ser extraído está acessível através de uma URL, e utilizando a classe WebClient ou até mesmo o ASP.NET Web API (se quisermos um controle mais refinado), é possível realizar o download e na sequência, encaminhar o resultado para este componente gerar o PDF. Para o nosso exemplo, suponhamos que queremos renderizar o conteúdo de uma view (MVC/Razor) em formato PDF, e isso irá nos obrigar a criar um código que dado o caminho até a view, ele é capaz de criar o contexto necessário, indicando inclusive as informações necessárias (dados) para que ela seja exibida, e o ASP.NET faz o trabalho de executar e disponibilizar em um objeto do tipo StringWriter, todo o HTML gerado.

protected string RenderViewToString(string viewPath)
{
    using (var writer = new StringWriter())
    {
        var controllerContext = this.ControllerContext;

        var viewContext =
            new ViewContext(
                controllerContext,
                new RazorView(controllerContext, viewPath, null, false, null),
                new ViewDataDictionary(),
                new TempDataDictionary(),
                writer);

        viewContext.View.Render(viewContext, writer);
        return writer.ToString();
    }
}

Depois do conteúdo HTML já gerado, vamos recorrer ao método GetPdfBytesFromHtmlString da classe PdfConverter (parte do componente Evo PDF), que dado o conteúdo HTML, retorna um array de bytes com todo o documento PDF já gerado. Note que além do HTML, este método também recebe um endereço HTTP(s), que é a URL base para que seja possível resolver as imagens, arquivos CSS, JavaScripts, etc. E, por fim, submetemos o resultado deste método para o método File exposto pela classe Controller, indicando que trata-se de um arquivo do tipo PDF. A marca d'água é por conta de que eu estou utilizando a versão de avaliação deste componente.

public class TesteController : Controller
{
    public ActionResult Index()
    {
        return File(
            new PdfConverter().GetPdfBytesFromHtmlString(
                RenderViewToString("~/Views/Teste/Conteudo.cshtml"), "http://localhost:1891/"),
            "application/pdf");
    }

    [HttpGet]
    public ActionResult Conteudo()
    {
        return View();
    }
}

Tags: ,

ASP.NET

Suportando apenas um formato de conteúdo

by Israel Aece 7. August 2014 16:38

O ASP.NET Web API já traz nativamente suporte a negaciação de conteúdo, ou seja, baseado na requisição do cliente (através de headers), a API é capaz de interpretar e gerar conteúdo de acordo com a necessidade do mesmo. Os formatadores são os responsáveis por realizar a leitura do conteúdo e materializar em um objeto, bem como serializar um objeto em um formato específico.

A coleção de formatadores está acessível através da propriedade Formatters da classe HttpConfiguration. Se utilizarmos o ASP.NET Web API, veremos que nativamente esta coleção já vem com 4 formatadores adicionados: JsonMediaTypeFormatter, XmlMediaTypeFormatter, FormUrlEncodedMediaTypeFormatter e JQueryMvcFormUrlEncodedFormatter. Com estes formatadores já adicionados, o ASP.NET Web API consegue recepcionar ou devolver os principais tipos de conteúdo de forma "mágica", sem qualquer tipo de customização.

Se quisermos que nossa API apenas suporte um determinado tipo de conteúdo, poderíamos simplesmente remover os formatadores indesejados. Só que o problema é que a requisição e resposta ainda continuarão passando por todo o processo para determinar qual o formato desejado, gastando um tempo desnecessário, já que não há necessidade de tomar qualquer decisão inerente ao formato do conteúdo, que será único. Para burlar tudo isso, é possível customizar o elemento que é responsável por toda essa negocição, e para isso, basta implementarmos a interface IContentNegotiator e, internamente, sempre retornarmos o formatador desejado.

public class JsonContentNegotiator : IContentNegotiator
{
    private readonly JsonMediaTypeFormatter formatter;

    public JsonContentNegotiator()
        : this(new JsonMediaTypeFormatter()) { }

    public JsonContentNegotiator(JsonMediaTypeFormatter formatter)
    {
        this.formatter = formatter;
    }

    public ContentNegotiationResult Negotiate(
        Type type, HttpRequestMessage request, IEnumerable<MediaTypeFormatter> formatters)
    {
        return new ContentNegotiationResult(formatter, new MediaTypeHeaderValue("application/json"));
    }
}

Repare que há uma sobrecarga no construtor para permitir ao criador a customização do formatador antes de passar para o negociador. Depois da classe criada, basta acoplá-la à execução substituindo o negociador padrão por este que acabamos de criar, conforme podemos notar no trecho de código a seguir:

public static void Register(HttpConfiguration config)
{
    config.Services.Replace(typeof(IContentNegotiator), new JsonContentNegotiator());
}

Tags: , , , ,

ASP.NET | CSD

Controllers no ASP.NET vNext

by Israel Aece 7. July 2014 21:51

Nos dias de hoje, ao criar um controller para o ASP.NET MVC, precisamos herdar da classe abstrata Controller; se precisamos criar um controller para o ASP.NET Web API, precisamos herdar da classe, também abstrata, ApiController. Apesar de ambos os frameworks terem uma API bastante semelhante, como eles foram desenvolvidos em épocas distintas e com objetivos diferentes, temos essa separação física.

Felizmente a próxima versão do ASP.NET (ainda chamada de vNext) unifica estes frameworks passam a fornecer uma API única e centralizada para a construção de qualquer recurso que desejamos expor através do protocolo HTTP. Sendo assim, não teremos mais duas classes, onde uma delas representa um controller para HTML e outra para Web API. Apesar disso, neste novo modelo passamos a ter os chamados Controllers POCO, ou seja, não há mais a necessidade nem de herdar da classe base Controller. O padrão para que o ASP.NET "descubra" o controller é que a classe seja pública, não abstrata e o nome seja sufixado com a palavra "Controller".

public class UsuariosController
{
    public string Get()
    {
        return "Israel Aece";
    }
}

Só que a classe Controller tem outras utilidades, e uma das principais é fornecer acesso à recursos inerentes (ActionContext, Url e ViewData) à requisição que está sendo executada. Só que nem sempre precisamos de todas essas informações dentro do controller. Esta versão do ASP.NET nos permite incluir apenas as propriedades que queremos utilizar no controller e o DefaultControllerFactory injeta a instância nestas propriedades durante a criação o controller.

public class UsuariosController
{
    public string Get()
    {
        return "Israel Aece";
    }

    public ActionContext ActionContext { get; set; }

    public IUrlHelper Url { get; set; }

    public ViewDataDictionary ViewData { get; set; }
}

Tags: , ,

ASP.NET

Compressão no ASP.NET Web API

by Israel Aece 19. June 2014 16:45

Em certas situações, quando um cliente executa uma operação de um serviço, o resultado pode ser uma grande massa de dados. Essa massa de dados pode ser qualquer coisa, desde os bytes de um arquivo até mesmo objetos que foram extraídos de um banco de dados.

Como todos sabem, o problema disso é a quantidade de informações que irá trafegar na rede, podendo causar uma grande lentidão, caso isso seja uma operação comum. A principal solução que geralmente utilizamos quando queremos diminuir o tráfego, é a compactação das informações. Isso fará com que a quantidade total de dados seja bem menor, aliviando consideravelmente a quantidade de informações que são trafegadas. Obviamente que a compactação tem um overhead quando você compacta ou descompacta, e isso deve ser levado em consideração para decidir se deve ou não optar por ela, mas na maioria das vezes, acaba compensando.

Quando estamos utilizando o ASP.NET Web API para construir e expor recursos, podemos implementar uma funcionalidade que permite a compactação das mensagens que são devolvidas para os clientes. O ASP.NET Web API não possui nativamente um mecanismo que permite a compactação das mensagens produzidas pelo serviço, mas graças ao modelo de estensibilidade que ele fornece, é possível recorrer as classes GZipStream e DeflateStream (do próprio .NET Framework) para gerar esse tipo de conteúdo.

O primeiro passo é criar um MessageHandler, que nos permite interceptar a requisição, e no interior do método SendAsync, chegamos até a mensagem de resposta (HttpResponseMessage) gerado pelo ASP.NET Web API (lembrando que neste momento a ação do controller já foi executada), e depois disso, analisamos o cabeçalho da requisição para se certificar se o cliente suporta ou não este tipo de codificação. Se sim, o cabeçalho AcceptEncoding deve ter como valor uma string com "gzip" ou "deflate", indicando qual dos formatos ele consegue interpretar.

public class CompressionHandler : DelegatingHandler
{
    protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        return base.SendAsync(request, cancellationToken).ContinueWith<HttpResponseMessage>(t =>
        {
            var response = t.Result;

            if (request.Headers.AcceptEncoding != null)
            {
                var encoding = request.Headers.AcceptEncoding.FirstOrDefault();

                if (encoding != null && !string.IsNullOrWhiteSpace(encoding.Value))
                    response.Content = new CompressedHttpContent(t.Result.Content, encoding.Value);
            }

            return response;
        });
    }
}

Uma vez que é possível determinar o suporte por parte do cliente, então criamos e sobrescrevemos o resultado da requisição com a instância da classe CompressedHttpContent, que também herda de HttpContent. É dentro desta classe que existe todo o trabalho para copiar o resultado gerado pelo controller, passar pelo compactador e gerar o mesmo conteúdo mais enxuto. Repare que o construtor recebe o conteúdo da mensagem atual e copia os headers existentes para a classe atual; note também que é incluído o header ContentEncoding com o mesmo tipo indicado pelo cliente, justamente para informar ao cliente que o conteúdo está compactado.

public class CompressedHttpContent : HttpContent
{
    private readonly HttpContent content;
    private readonly string compressorType;

    public CompressedHttpContent(HttpContent content, string compressorType)
    {
        this.content = content;
        this.compressorType = compressorType;

        ConfigHeaders();
    }

    private void ConfigHeaders()
    {
        foreach (var item in this.content.Headers)
            this.Headers.TryAddWithoutValidation(item.Key, item.Value);

        this.Headers.ContentEncoding.Add(this.compressorType);
    }

    protected override Task SerializeToStreamAsync(Stream stream, TransportContext context)
    {
        var compressorStream = CreateCompressorStream(stream);

        return this.content.CopyToAsync(compressorStream).ContinueWith(t => compressorStream.Dispose());
    }

    private Stream CreateCompressorStream(Stream output)
    {
        return 
            this.compressorType == "gzip" ?
            (Stream)new GZipStream(output, CompressionMode.Compress, true) : 
            new DeflateStream(output, CompressionMode.Compress, true);
    }

    protected override bool TryComputeLength(out long length)
    {
        length = -1;
        return false;
    }
}

O método SerializeToStreamAsync é invocado pelo próprio runtime, que passará o stream de saída e o envolveremos no stream de compactação, para que ao copiar o conteúdo atual para o stream de saída, ele passe pelo algoritmo que efetivamente realiza a compactação. Aqui seria interessante melhorar o código, para que seja possível acoplar novas implementações de novos compactadores. Para isso poderíamos criar uma abstração (IHttpCompressor) e implementá-lo para cada um dos compactadores que queremos que sejam suportados pela API.

Este código por si só não funciona. É necessário incluir o message handler na coleção exposta pelo ASP.NET Web API, e para isso, recorreremos as configurações da API, conforme é mostrado no código abaixo:

config.MessageHandlers.Add(new CompressionHandler());

Para mensurar o ganho gerado por este código, ao acessar um método que até então retornava um resultado de 562 Bytes de tamanho, passa a devolver o mesmo conteúdo com apenas 28 Bytes.

GET http://127.0.0.1:9393/api/Teste HTTP/1.1
Host: 127.0.0.1:9393
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

HTTP/1.1 200 OK
Content-Length: 28
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
Date: Thu, 19 Jun 2014 19:08:08 GMT

RESULTADO COMPACTADO, OMITIDO POR QUESÕES DE ESPAÇO

Vale lembrar que o cliente que consome este serviço precisa saber lidar com este tipo de resultado. Caso o consumo do serviço esteja sendo feito através do próprio ASP.NET Web API (HttpClient), então ele já possui o suporte interno para descompactar o resultado, sem que seja necessário qualquer customização. Ao criar o HttpClient, podemos recorrer à um segundo construtor, que recebe a instância da classe HttpClientHandler, que por sua vez, expõe uma propriedade chamada AutomaticDecompression, que também é utilizada para indicar ao serviço que possui suporte para descompactação (Accept-Encoding) daquele formato.

using (var client = new HttpClient(new HttpClientHandler()
{
    AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate
}))
{
    //...
}

Tags: , , ,

ASP.NET | CSD

Expondo vídeo através do ASP.NET Web API

by Israel Aece 27. May 2014 09:13

Além de possibilitar o retorno de tipos mais simples, tais como inteiros, strings e também de objetos que representam o nosso negócio (Produto, Pedido, Cliente, etc.), o ASP.NET Web API também é capaz de retornar outros tipos de recursos, tais como vídeos ou músicas, permitindo ao cliente ir consumindo o mesmo sob demanda, ou seja, na medida em que ele vai tocando, o conteúdo vai sendo baixado, sem a necessidade de trazer todo o conteúdo antes de utilizar. Isso garantirá ao cliente ouvir/assistir e decidir abortar sem a necessidade de realizar o download completo do arquivo, que muitas vezes é grande.

Para este tipo de cenário temos a classe PushStreamContent. Essa classe herda de HttpContent e, consequentemente, pode ser definida como o conteúdo da mensagem de resposta. Essa classe permite estabelecer a comunicação entre o serviço e o cliente através de um stream, que ao serem escritas informações nele, viajará até o cliente para que ele decida o que fazer com o mesmo. O construtor desta classe permite a iniciliazação através de um delegate do tipo Func<>, que entre os parâmetros que são fornecidos, um deles é justamente o stream que liga o cliente ao serviço.

Ao utilizar este stream, o conteúdo será encaminhado ao cliente diretamente. Para o exemplo, vamos permitir ao cliente informar o nome do vídeo que ele deseja assistir, e o serviço será responsável por extrair este arquivo do disco, particionar os bytes do arquivo (através de um buffer de 5 MB), e dentro do laço while, ele vai enviando estes "pedaços" ao cliente de forma assíncrona. Abaixo está o controller completo com esta funcionalidade.

public class EntretenimentoController : ApiController
{
    private const int TamanhoDoBuffer = 1024 * 32;
    private readonly string Diretorio;

    public EntretenimentoController()
    {
        this.Diretorio = HttpContext.Current.Server.MapPath("~/App_Data");
    }

    [HttpGet]
    public HttpResponseMessage BuscarVideo(string nomeDoVideo)
    {
        return new HttpResponseMessage(HttpStatusCode.OK)
        {
            Content = new PushStreamContent(
                async (stream, content, context) =>
                    await ExtrairRecurso(Path.Combine(Diretorio, nomeDoVideo), stream), "video/mp4")
        };
    }

    private static async Task ExtrairRecurso(string fileName, Stream output)
    {
        var buffer = new byte[TamanhoDoBuffer];
        var read = 0;

        using (var input = File.OpenRead(fileName))
            while ((read = input.Read(buffer, 0, TamanhoDoBuffer)) > 0)
                await output.WriteAsync(buffer, 0, read);
    }
}

O consumo do vídeo pode ser realizado através dos novos recursos do HTML 5, que através da tag <video /> permite associar uma URL que produz o conteúdo, fazendo o trabalho de acumular e ir exibindo o vídeo que está sendo retornado. O código abaixo ilustra como embutir o player no HTML:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title></title>
</head>
<body>
    <video width="480" height="320" controls="controls" autoplay="autoplay">
        <source src="/api/Entretenimento/BuscarVideo?nomeDoVideo=TranneNoi.mp4"
                type="video/mp4">
    </video>
</body>
</html>

Por fim, para conseguir perceber o resultado, a imagem abaixo (clique para ampliar) ilustra de um lado o Visual Studio com o breakpoint parado no interior do while, e apesar de não perceber isso na imagem (porque ela é estática), o vídeo também está parado esperando que se escreva mais bytes no stream para que ele possa exibir, e na medida em que se passa pelo loop, logo o vídeo volta a ser executado até que, obviamente, pare de receber novamente os bytes ou quando o mesmo já estiver encerrado.

Clique para Ampliar

Tags: ,

ASP.NET

Buffer e Streaming no ASP.NET Web API

by Israel Aece 26. May 2014 21:02

Como sabemos, o ASP.NET Web API permite o upload e download de arquivos para uma determinada ação dentro do controller, e apesar de podermos receber e retornar sem maiores problemas estes arquivos, precisamos nos atentar à algumas configurações que precisamos realizar dependendo do tamanho dos arquivos que desejamos receber.

Devido a isso, precisamos explicitamente realizar essas configurações, já que o ASP.NET vem com algumas definições padrões que talvez não irão satisfazer as nossas necessidades. Como sabemos, uma das formas de hospedarmos a nossa API é utilizando a própria infraestrutura do ASP.NET, que por sua vez, deve ser colocado dentro do IIS. Tanto o IIS quanto o ASP.NET possuem limitadores que abortam a requisição caso a mesma seja maior que um determinado valor.

Um velho conhecido de quem trabalha com o ASP.NET é o arquivo Web.config. Dentro dele há um elemento chamado httpRuntime, que possui entre inúmeras configurações que interferem na execução daquela aplicação ASP.NET, uma que é justamente o tamanho máximo (em bytes) que a requisição deve ter. Abaixo estou definindo que a mesma não possa exceder 5 MB, caso contrário, o cliente receberá um erro de código 500 (Internal Server Error), indicando o excesso de informações que foi submetida.

<system.web>
  <httpRuntime maxRequestLength="5120" />
</system.web>

É importante que se mantenha este valor no limite viável para sua aplicação, para que não abra demais e, consequentemente, comece a receber requisições mal intencionadas e que poderão comprometer o bom desempenho do servidor onde a API está sendo hospedada e executada.

Muitas vezes a necessidade de alterar essas configurações tem a ver com o recebimento de arquivos (uploads). Apesar de alterarmos essa configuração, ainda há algo que possamos fazer para que seja possível ter uma melhor performance durante o processamento da requisição. Por padrão, o ASP.NET Web API faz o buffer da mensagem completa em memória, para depois disso, processá-la. Por mais que o valor informado na atributo acima seja enorme, se você não tiver memória suficiente, a requisição não será processada.

Felizmente o ASP.NET Web API permite alterar esse comportamento, fazendo com que a requisição seja convertida em um modelo de streaming, repassando os bytes para o destino diretamente, sem a necessidade de alocar memória para isso. Tudo o que precisamos fazer é implementar a interface IHostBufferPolicySelector e definir qual o modelo de buffer a ser utilizado, podendo definir um padrão para a entrada (upload) e outro para a saída (download).

Já existe uma implementação padrão desta interface que é a classe WebHostBufferPolicySelector (já utilizada pelo ASP.NET Web API). Essa classe permite sobrescrever os mesmos métodos expostos pela interface (UseBufferedInputStream e UseBufferedOutputStream), onde ambos os métodos, retornam um valor boleano indicando se deve ou não efetuar o buffer da requisição/resposta. Para o exemplo, vamos apenas nos preocupar com as requisições, ou seja, os uploads enviados à API, não devem ser colocados na memória. Apesar de poder condicionar ao controller aqui, optei por não realizar o buffer se o tipo de conteúdo da requisição se tratar de um formulário defina o multipart no enctype, ou seja, trata-se de um upload. Note que não colocamos o controller/ação em hard-code aqui.

public class NoBufferPolicySelector : WebHostBufferPolicySelector
{
    public override bool UseBufferedInputStream(object hostContext)
    {
        var context = hostContext as HttpContextBase;

        if (context != null)
            if (context.Request.ContentType != null && context.Request.ContentType.Contains("multipart"))
                return false;

        return true;
    }
}

Depois da classe acima criada, é necessário acoplarmos a mesma a execução do ASP.NET Web API, e para isso, basta recorrermos à coleção de serviços exposta pela classe HttpConfiguration, e lá substituirmos o seletor padrão por este que acabamos de criar. O código abaixo ilustra essa configuração.

public static class WebApiConfig
{
    public static void Register(HttpConfiguration config)
    {
        config.Services.Replace(typeof(IHostBufferPolicySelector), 
            new NoBufferPolicySelector());

        //Outras configurações
    }
}

Vale lembrar que essa configuração é válida somente quando estamos optando por hospedar as APIs no IIS. Quando optamos pelo modelo de self-host, então devemos continuar recorrendo ao enumerador TransferMode, criado e exposto pelo API do WCF.

Tags: , , ,

ASP.NET

Powered by BlogEngine.NET 1.5.0.0
Theme by Mads Kristensen

Sobre

Meu nome é Israel Aece e sou especialista em tecnologias de desenvolvimento Microsoft, atuando como desenvolvedor de aplicações para o mercado financeiro utilizando a plataforma .NET. [ Mais ]

Twitter

Indicações

Introdução ao ASP.NET Web API - e-Book