Arquivo da categoria: ASP.Net

.NET Standard – Você precisa conhecer!

Publicado em por

.NET Standard é a nova palavra do momento, quem acompanha de perto as novidades do mundo .NET com certeza já deparou com este novo conceito e é realmente muito importante que você compreenda bem o que ele significa.

O .NET Standard é um conceito essencial para compreender a unificação das plataformas .NET sendo que atualmente podemos entender como 3 plataformas:

.NET Standard

Por que precisamos de um padrão?

O .NET Framework foi lançado em meados de 2002 no formato de um framework único para desenvolvimento na plataforma Windows. Com o passar do tempo ganhou suporte para Web, Silverlight, WCF, WPF, etc…

Após o lançamento do .NET surgiram outros frameworks como Mono, Unity, etc. Que são implementações open-source do .NET Framework e aceitam a linguagem C#, pois implementam os padrões ECMA do C# e o CLR do .NET.

E para finalizar ainda temos o .NET Core o mais recente “sabor” de .NET Framework 100% open-source e multi-plataforma.

Problemas a vista

  • Sendo que todos estes “sabores” de frameworks suportam a linguagem C#, seria possível escrever um único código e rodar em qualquer plataforma?
  • Posso escrever uma biblioteca em .NET 4.6.1 e utilizá-la como referência no .NET Core?
  • É possível garantir que o código não irá quebrar ao trocar a versão do framework?

Não! Sempre existiram diversas limitações. Tanto no suporte das funcionalidades de cada versão quanto no número de APIs suportadas em cada framework.

Para que o .NET continue evoluindo rapidamente é necessário evitar a fragmentação entre tantas versões de frameworks e proporcionar a escrita de um código único para qualquer plataforma. A solução é implementar um padrão para que todas as versões dos frameworks suportem o mesmo conjunto de APIs.

Conceituando o .NET Standard

O .NET Standard não é mais um “sabor” de .NET, você não instala o .NET Standard na sua máquina e também não devemos considerar o .NET Standard uma nova tecnologia.

O .NET Standard é uma interface, uma espécie de contrato que define a lista de APIs que aquela determinada versão do .NET deve suportar. Para entender de forma muito simples o conceito do .NET Standard imagine o seguinte cenário:

.NET Standard Analogia

O David Fowler também criou uma analogia bem interessante sobre o assunto.

Entenda que o .NET Standard é uma espécie de interface que define as APIs que cada versão do .NET irá oferecer suporte. O código do .NET Standard não possui implementação de comportamento, apenas a declaração das classes e métodos. Através deste padrão único conseguiremos uma total compatibilidade de um código .NET Framework para .NET Core por exemplo.

Mas o PCL não serve para isto?

O PCL (Portable Class Libraries) resolvia isto mas de uma outra forma, uma forma bem menos eficiente e que limitava a entrada de novas plataformas. O .NET Standard substituiu o PCL.

Como o .NET Standard resolve esta questão?

O código será compilado para uma versão específica do framework .NET que é suportado em versões específicas do .NET Standard. Cada versão do .NET Standard suporta um número determinado de APIs.

.NET Standard Versões

O .NET Standard 2.0 suporta o .NET Core 2.0 e .NET Framework 4.6.1.
No futuro suportará também as novas versões do Mono, UWP e Xamarin.

Um ponto muito interessante é a evolução da versão 1.6 para a versão 2.0:

Versão #APIs Crescimento%
1.0 7,949
1.1 10,239 +29%
1.2 10,285 +0%
1.3 13,122 +28%
1.4 13,140 +0%
1.5 13,355 +2%
1.6 13,501 +1%
2.0 32,638 +142%

A versão 2.0 do .NET Standard suporta 142% mais APIs que a versão anterior. Um salto incrível no número de APIs suportadas.

Muita calma nessa hora!

Isto não significa que um código escrito para .NET Framework 4.6.1 seja 100% compatível com o .NET Core 2.0.
Existem muitas APIs no .NET Framework que não são implementadas pelo .NET Standard 2.0, logo também não serão suportadas no .NET Core 2.0.

A única compatibilidade entre versões .NET são aquelas cobertas pelo .NET Standard.

Como descobrir se o código está 100% coberto pelo .NET Standard?

Utilize o API Port para analisar se o código está 100% coberto por uma versão específica do .NET Standard. É possível rodar o analyzer via linha de comando ou via Visual Studio.

apiport analyze -f C:\src\mylibs\ -t “.NET Standard,Version=2.0”

Com .NET Standard é muito mais fácil!

O .NET Standard foi criado para que o compartilhamento e a reutilização de código entre várias plataformas .NET se tornem muito mais fáceis.

Desenvolver um Nuget Package será muito mais fácil, basta apontar o target da class library para uma versão específica do .NET Standard ao invés de distribuir uma versão específica para cada framework.

Saiba mais

Documentação oficial
https://docs.microsoft.com/pt-br/dotnet/standard/net-standard

Explore quais APIs são suportadas em cada versão do .NET Standard
https://docs.microsoft.com/en-us/dotnet/api/?view=netstandard-2.0

Confira a FAQ do .NET Standard
https://github.com/dotnet/standard/blob/master/docs/faq.md

Acompanhe a atualização de versões do .NET Standard
https://github.com/dotnet/standard/blob/master/docs/versions.md

Caso esteja interessado em conhecer mais sobre ASP.NET, DDD, Padrões de Arquitetura e boas práticas de desenvolvimento não deixe de conferir as ementas dos meus cursos:

Vamos continuar a troca de experiências, deixe seu comentário abaixo. Se gostou e concorda com o artigo, compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis.

Turbinando sua aplicação ASP.NET no IIS

Publicado em por

Toda aplicação ASP.NET requer um processo de compilação em memória no servidor e isto leva um tempo perceptível por nossos usuários. Aprenda como evitar esse comportamento.

Turbinando sua aplicação ASP.NET no IIS

Na minha vida de consultor eu sempre ouço a mesma pergunta dos meus clientes:
Meu site fica lento na primeira chamada toda vez que faço um deploy ou quando o pool do IIS recicla naturalmente.

Antes de tudo é importante deixar claro que não tem como fugir do processo de reciclagem do pool do IIS, ele pode ocorrer naturalmente por N fatores ou agendado conforme sua configuração.

A demora natural na primeira chamada de uma aplicação ASP.NET é o processo do IIS compilando o assembly da sua aplicação e disponibilizando ele num cache, esse cache é usado nas próximas chamadas e assim sua aplicação volta a responder normalmente sem nenhuma demora aparente. Toda vez que o pool do IIS recicla a memória esse cache é perdido.

Nós não queremos que nossos usuários sejam obrigados a esperar este tempo de compilação que pode chegar em cerca de 30 segundos dependendo do tamanho da aplicação, é por isso que o IIS possui uma feature pouco utilizada chamada de
IIS Auto-Start ou Application Initialization

Para habilitar esse comportamento no seu IIS é necessário instalar o módulo de Application Initialization no seu servidor e seguir alguns passos na configuração do IIS.

*A mesma configuração pode ser feita através da edição dos arquivos de configuração no servidor. Eu prefiro fazer no IIS diretamente, você encontrará esta outra abordagem no link de referência no final do post.

O resultado é muito satisfatório, ao invés da aplicação demorar mais de 10 segundos para responder ela passa a demorar 1 ou 2 segundos.

Para abordar todos os passos necessários em detalhes eu gravei um vídeo de 16 minutos mostrando todo o processo de configuração.

* Assine meu canal no Youtube 🙂

Referências

Se você estiver interessado em conhecer mais e aprender como desenvolver aplicações com uma arquitetura responsável utilizando DDD, TDD, BDD, aplicando os princípios SOLID, diversos Design Patterns e escrevendo testes de unidade conheça meus cursos:

Vamos continuar a troca de experiências, deixe seu comentário abaixo, se gostou e concorda com o artigo compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis. ;)

O ASP.NET Brasil Conference 2016 foi um sucesso!

Publicado em por

O ASP.NET Brasil Conference é o maior evento da América Latina sobre ASP.NET e em sua 3a edição recebeu mais de 600 participantes.

Eu como organizador do ASP.NET Brasil Conference estou extremamente satisfeito e muito feliz com o resultado do evento. Casa cheia, público animado, palestras de alto nível e infra-estrutura completa. Este foi um evento épico para ficar na história.

Como palestrante de eventos técnicos não é comum falar para um público tão grande, a maioria dos eventos não costumam reunir grandes quantidades de pessoas em uma única trilha e o sucesso de público foi um dos grandes motivos que tornou esta edição do evento tão especial.

Organizar um evento deste porte não é fácil, principalmente para uma equipe tão enxuta de três pessoas. Sim foram três pessoas, uma full-time e duas partial-time que rodaram todo o evento em um pouco menos de 6 meses de planejamento e execução.

Acompanhe a evolução do evento em 2014, 2015, 2016

Desculpe, nada foi encontrado.

 ASP.NET Brasil Conference 2016 – Sucesso de público

ASP.NET Brasil Conference 2016 - Keynote

ASP.NET Brasil Conference 2016 - Sucesso de Público

Um evento para a comunidade técnica

Diferente de outros eventos, o ASP.NET Brasil Conference não é um evento realizado para gerar lucros aos organizadores, todo o valor arrecadado é utilizado para custear o próprio evento e para fazer caixa para os próximos, assim conseguimos oferecer para nossos participantes diversos tipos de brindes e prêmios que também é um grande diferencial do evento em comparação aos outros do mesmo porte.

ASP.NET Brasil Conference 2016 - Brindes para os participantes

ASP.NET Brasil Conference 2016 - Prêmios Sorteados

Feedback excelente

Todos os participantes que preencheram as fichas de avaliação pontuaram em grande maioria entre bom e excelente todos os aspectos do evento. Tivemos bastantes feedbacks muito positivos nas redes sociais também.

Uma grande novidade para 2017

Anunciamos no keynote uma grande novidade, estamos planejando para 2017 um evento ainda maior, muitas trilhas e um público previsto de 1500 pessoas. Este novo evento será o DevXperience ou se preferir DevX.

ASP.NET Brasil Conference 2016 - Anuncio do DevXperience - DevX

Acompanhe as novidades do DevX no Facebook e Twitter e fique por dentro das trilhas, palestras e garanta sua inscrição o quanto antes.

Gostaria de agradecer a todos os participantes, palestrantes e staffs. Vocês fizeram do ASP.NET Brasil Conference 2016 um evento incrível!

No próximo post farei uma lista das palestras e disponibilizarei o material utilizado pelos palestrantes.
Até a próxima e nos vemos no DevXperience.

10 Motivos para ir ao ASP.NET Brasil Conference 2016

Publicado em por

Participar de eventos técnicos como o ASP.NET Brasil Conference é algo que todo desenvolvedor deve fazer, pois é a melhor maneira de absorver conhecimento de forma prática e manter-se sempre atualizado.

Eventos técnicos são ótimas fontes de conhecimento para quem deseja se atualizar de forma rápida, as vezes é muito difícil encontrar um evento que seja focado em atender um conhecimento específico e é por este motivo que apresento 10 motivos para ir ao ASP.NET Brasil Conference 2016.

ASP.NET Brasil Conference 2016

 1 – Atualização tecnológica

O ASP.NET Brasil Conference é um evento planejado e focado em atender a necessidade de atualização tecnológica que todo desenvolvedor possui. Estar atualizado é o segredo para o crescimento de carreira e para o surgimento de novas oportunidades de trabalho.

2 – Um novo mercado para o .NET

O .NET e o ASP.NET entraram em uma nova era! Um novo stack totalmente reescrito do zero, multi-plataforma, mais de 2000% mais rápido e focado em escalabilidade em nuvem.
Com esta nova era do .NET o mercado que conhecemos irá mudar muito, inúmeras novas oportunidades irão surgir e você precisa estar preparado.

3 – Grade de palestras focada

A grade de palestras do ASP.NET Brasil Conference foi modelada com o objetivo de fornecer o máximo de conteúdo necessário para lhe atualizar nesta nova era do .NET, todas as palestras irão apresentar de forma prática e teórica as grandes novidades e novidade é o que não falta.

4 – Palestrantes de grande reconhecimento

Todos os palestrantes são profissionais de grande reconhecimento no mercado e que trabalham no dia-a-dia com as tecnologias que irão apresentar. Tivemos um grande cuidado em selecionar os palestrantes conforme seu foco técnico para lhe oferecer uma grande experiência de troca de conhecimentos.

5 – Networking

Teremos 600 participantes, é uma ótima oportunidade de conhecer novos profissionais e gerar diversas oportunidades. Buscando um novo emprego? Procurando a pessoa certa para lançar uma Startup? Gostaria de fazer novas amizades dentro de sua área? O ASP.NET Brasil Conference é uma ótima oportunidade!

6 – Aprender a vender

Já aprendeu sobre uma nova tecnologia, gostou dela mas na hora de apresentar na empresa faltaram palavras para vender a ideia? No ASP.NET Brasil Conference todas as palestras são focadas no cenário ideal para sua aplicação, assim você poderá aumentar seu repertório técnico para propor as inovações tecnológicas que sua empresa precisa.

7 – Melhor custo / benefício

O quanto de investimento financeiro seria necessário para aprender sobre todos os assuntos abordados na grade de forma independente? Calcule o valor de sua hora, livros e até cursos que poderiam ser necessários para adquirir o conhecimento desejado.
Investir em um evento de um dia é uma ótima opção que com certeza lhe poupará muito tempo e dinheiro.

8 – Se envolver com a comunidade técnica

A comunidade técnica .NET é muito unida e sempre contamos com pessoas bem intencionadas para ajudar numa dúvida ou opinião, fazer parte da comunidade é uma ótima maneira de criar novos contatos e fazer um ótimo networking.
No ASP.NET Brasil Conference teremos muitos colaboradores da comunidade técnica presentes.

9 – Brindes e prêmios

É muito bom ir a um evento e ganhar camiseta, adesivos e outros brindes da tecnologia que trabalhamos. É melhor ainda quando além disso levamos para casa um prêmio de alto valor. No ASP.NET Brasil Conference 2015 distribuímos camisetas, adesivos e uma bag para todos os participantes, também sorteamos 1 Xbox One e 2 celulares Lumia. Para este ano divulgaremos os brindes e prêmios em breve.

10 – Local privilegiado

Escolhemos uma estrutura muito bem localizada para facilitar o acesso de todos ao evento. Além da localização também priorizamos o conforto, teremos um grande telão, cadeiras confortáveis e uma disposição em formato de cinema / teatro para ninguém perder um detalhe do conteúdo. Confira abaixo uma visão 360º do local do evento.

O que está esperando? Junte se a nós neste grande evento!

Confira nossa agenda, palestrantes e demais detalhes no nosso site:
www.aspnetbr.com

Estamos com um valor promocional para compra antecipada, seja rápido para garantir o seu, utilize o sistema de compras abaixo para agilizar sua inscrição.
Espero lhe ver la! 

Introdução ao ASP.NET Core 1.0

Publicado em por

Estes últimos dois anos foram de muitas mudanças e novidades para o ASP.NET, que agora ganhou um novo nome. Conheça o ASP.NET Core 1.0.

O ASP.NET Core 1.0 é uma novidade de baixo impacto tecnológico, trata-se do novo nome do novo ASP.NET.

ASP.NET Core 1.0

Desde que anunciado o novo ASP.NET já tivemos alguns nomes, vamos recapitular:

  • ASP.NET vNext
  • ASP.NET 5
  • ASP.NET Core 1.0

Por que não ASP.NET 5?
O nome ASP.NET 5 não foi muito bem recebido por muitos colaboradores da comunidade, gerou diversas reclamações como podemos ver nesta issue do GitHub. O ASP.NET 5 não é apenas uma nova versão do ASP.NET e sim um ASP.NET totalmente novo, reescrito para trabalhar de forma diferente do clássico ASP.NET que já tem 15 anos de existência.

Outro fato que causou confusão foi o MVC 6. ASP.NET 5, MVC 6, Razor 4, SignalR 3, Identity 3, Entity Framework 7 e .NET Core 5. Quantos números para uma tecnologia totalmente nova certo? Para deixar muito claro que o novo ASP.NET substitui o antigo ele precisou mudar de nome outra vez.

Não foi apenas o ASP.NET que mudou de nome:

  • ASP.NET 5 => ASP.NET Core 1.0
  • ASP.NET MVC 6 => ASP.NET Core MVC 1.0
  • .NET Core 5 => .NET Core 1.0
  • Entity Framework 7 => Entity Framework Core 1.0 (ou EF Core 1.0)

Algumas tecnologias citadas acima não tiveram anúncios de novos nomes, porém acredito que possa surgir mais novidades.

Por que 1.0? É um novo ASP.NET, logo todo novo conceito precisa surgir de uma versão inicial, pois não é uma continuidade da tecnologia, é uma nova tecnologia.

Algumas dúvidas podem surgir:

Acompanhei todas as mudanças do ASP.NET 5 agora vou precisar aprender tudo de novo?
Não! Esta mudança anunciada reflete apenas na mudança do nome.

Estou começando a estudar ASP.NET agora, qual versão devo estudar?
Eu recomendo fortemente que estude o ASP.NET MVC 5 e o ASP.NET Core 1.0. O primeiro para atender uma demanda enorme de mercado que não vai sumir em menos de 3 anos e o segundo para poder trabalhar com a nova plataforma em futuros projetos.

Qual a diferença do ASP.NET MVC 5 para o ASP.NET Core 1.0?
É um novo ASP.NET porém ambos trabalham com o MVC, logo a forma de desenvolver não muda muito, o que muda é a tecnologia do stack do ASP.NET, a maneira que ele funciona. Certamente tem muitas mudanças de um para outro, mas conhecendo um é muito fácil entender o outro.

Vou começar um projeto agora, devo desenvolver em ASP.NET Core 1.0?
Uma solução de mercado deve ser escrita com uma tecnologia madura, bem testada e que seja pronta. O ASP.NET MVC 5 (ASP.NET 4.6) ainda é a melhor opção neste momento, pois ainda não temos uma versão 1.0 (RTM) para o ASP.NET Core 1.0, ela virá em breve porém mesmo assim não estará completa como expliquei neste artigo.

Recomendo que utilizem o ASP.NET Core 1.0 em projetos de estudo, pois a viabilidade comercial de uma aplicação não pode depender de possíveis bugs / limitações de uma nova tecnologia.

Por onde começar com o ASP.NET Core 1.0?
Recomendo utilizar o guia do site Get ASP.NET.

Ainda vale a pena estudar ASP.NET WebForms?
Existe uma grande demanda de mercado para WebForms, cerca de 50% de todas aplicações ASP.NET ainda são WebForms, logo se pretende atender a demanda de manutenção em aplicações WebForms é necessário conhecer sim. Minha recomendação é focar os estudos em ASP.NET MVC 5 e ASP.NET Core 1.0. Não recomendo criar novas aplicações em WebForms. Estude apenas se existir a necessidade.

O WebForms faz parte do novo ASP.NET?
Não. O WebForms está pronto e faz parte do ASP.NET 4.6, não irá fazer parte do ASP.NET Core 1.0, pois é tecnologicamente incompatível, a única forma de desenvolvimento em ASP.NET Core 1.0 é o MVC.

O ASP.NET e toda plataforma de desenvolvimento .NET está passando por uma grande revolução para atender o mercado com excelência, segurança e performance. Este é apenas o primeiro passo de uma longa e nova jornada. Mantenha-se atento às novidades, elas vão surgir em um espaço de tempo cada vez menor.

Eu também fiz um vídeo de 8 minutos sobre este assunto, vale a pena conferir:

* Assine meu canal no Youtube 🙂

Referências

Se você estiver interessado em conhecer mais e aprender como desenvolver aplicações com uma arquitetura responsável utilizando DDD, TDD, BDD, aplicando os princípios SOLID, diversos Design Patterns e escrevendo testes de unidade conheça meus cursos:

Vamos continuar a troca de experiências, deixe seu comentário abaixo, se gostou e concorda com o artigo compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis. ;)

Self-Hosting com SignalR e integração via ASP.NET MVC

Publicado em por

O ASP.NET SignalR é um framework de comunicação em tempo real que pode ser utilizado para diversas funcionalidades, inclusive para integração de comunicação entre sistemas de diferentes plataformas.

Caso não conheça o ASP.NET SignalR aprenda em detalhes neste artigo e nesta palestra.

Integração de Comunicação em Tempo Real com ASP.NET SignalR

O ASP.NET SignalR vem sendo amplamente utilizado em diversos cenários de comunicação em tempo real. Muitas vezes a própria solução Web implementa os Hubs e gerencia o recebimento e distribuição de mensagens.

Existem outros cenários em que é necessário desacoplar o lado server do SignalR da aplicação Web. Muitas vezes a informação a ser distribuída pode vir de outros serviços, outras plataformas e etc. É possível utilizar SignalR nesses casos? Sim, é possível!

O SignalR é implementado seguindo a especificação do OWIN e pode trabalhar em uma aplicação Web ou no modo Self-Host em um Windows Service ou aplicação console.

Proponho um cenário hipotético: Existem N broadcasts sendo distribuídos de diversas aplicações independentes da Microsoft e é necessário que a comunicação seja transmitida em tempo real para outras plataformas (Web, Desktop, Mobile). É necessário utilizar uma solução única para atender esta demanda e com baixo esforço de desenvolvimento.

Este cenário é muito similar ao da imagem utilizada no início do artigo e segue o fluxo a seguir:

  1. O Windows Service implementa uma forma de receber a comunicação vinda das demais aplicações.
  2. Os Hubs do SignalR no Windows Service distribuem as informações recebidas à todos os clientes conectados.
  3. Os clientes conectados recebem a comunicação em tempo real e se necessário podem encaminhar novas informações para o Windows Service.
  4. O Windows Service recebe as informações de um cliente e redistribui para todos novamente (como num chat).

Desenvolvi a solução deste cenário utilizando um Windows Service gerando dados de tempo, dados aleatórios de valores e trabalhando com uma comunicação via chat.

Aplicação ASP.NET MVC recebendo em tempo real as informações do Windows Service no Chrome e no Edge.

A solução está publicada em meu GitHub

  • Para testes de desenvolvimento não é necessário instalar o serviço (Windows Service), basta setar os dois projetos para iniciarem juntos e realizar um Debug.
  • É possível implementar autenticação para transmitir a comunicação apenas para clientes com a devida permissão.
  • É possível implementar algum Retry Pattern como o Polly caso haja alguma falha na entrega da comunicação.

Se você estiver interessado em conhecer mais e aprender como desenvolver aplicações Web com arquitetura baseada em DDD, aplicando os princípios SOLID, diversos Design Patterns e escrevendo testes de unidade inscreva-se em meu curso:

Vamos continuar a troca de experiências, deixe seu comentário abaixo, se gostou e concorda com o artigo compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis. ;)

Ordene manualmente os seus scripts via Bundles

Publicado em por

A feature Bundles e Minification foi introduzida a partir da versão do ASP.NET MVC 4 e trouxe bastante praticidade, porém precisamos de um ajuste manual para obter a ordenação exata dos scripts.

Utilizar os Bundles da forma tradicional pode ocasionar alguns problemas na execução de nossos scripts devido ao seu padrão de ordenação. Encontrar a solução para estes problemas pode tomar algumas horas de trabalho se não observarmos corretamente o comportamento dos Bundles.

Um exemplo simples:
Para utilizar a biblioteca de globalização de validações “jquery.validate.globalize.js” certamente precisaremos da biblioteca “jquery.validate.js” e “globalize.js”, pois são dependências para que a validação funcione de forma globalizada. Portanto para o browser poder executar os métodos de “jquery.validate.globalize.js” é necessário ter carregado previamente a bibliotecas que são dependências.

Utilizando os Bundles de forma tradicional teríamos uma configuração parecida com o exemplo a seguir.

// Adicionando jQuery
bundles.Add(new ScriptBundle("~/bundles/jquery").Include(
            "~/Scripts/jquery-{version}.js"));

// Adicionando Validação, e Globalização
bundles.Add(new ScriptBundle("~/bundles/jqueryval").Include(
            "~/Scripts/jquery.validate.js",
            "~/Scripts/globalize.js",
            "~/Scripts/jquery.validate.globalize.js"));

E por consequência o código HTML gerado para interpretação do browser não seria o esperado.

Bundles Uncaught ReferenceError

Uncaught ReferenceError: Globalize is not defined

Este problema ocorreu por que o Bundle não gerou os scripts na ordem em que foram declarados como no código acima, pois sua ordenação padrão não respeita a ordem da declaração. Logo a biblioteca “jquery.validate.globalize.js” não encontrou sua dependência e não executou suas funções.

Existem algumas formas de resolver este problema, minha recomendação é criar uma classe de ordenação que respeita a ordem em que as bibliotecas foram declaradas. Esta classe pode ser criada no próprio arquivo “BundleConfig.cs” para manter a simplicidade da implementação.

public class AsIsBundleOrderer : IBundleOrderer
{
    public IEnumerable<BundleFile> OrderFiles(BundleContext context, IEnumerable<BundleFile> files)
    {
        return files;
    }
}

E a forma de declaração do Bundle precisa ser modificada para fazer uso desta nova ordenação.

// Adicionando jQuery
bundles.Add(new ScriptBundle("~/bundles/jquery").Include(
            "~/Scripts/jquery-{version}.js"));

// Adicionando Validação, e Globalização
// Utilizando ordenação manual
var valBundle = new ScriptBundle("~/bundles/jqueryval").Include(
    "~/Scripts/jquery.validate.js",
    "~/Scripts/globalize.js",
    "~/Scripts/jquery.validate.globalize.js");

valBundle.Orderer = new AsIsBundleOrderer();

bundles.Add(valBundle);

Utilizamos algumas linhas a mais, porém garantimos a ordenação da forma que o browser precisa para poder executar tudo corretamente. O resultado é como o esperado.

Bundles Order Ok

Como podemos conferir é muito importante estar atento a este comportamento dos Bundles para evitar possíveis problemas e por consequência perder um tempo precioso de trabalho.

* Esta abordagem vale também para os StyleBundles que trabalham com CSS.

** Caso esteja trabalhando com o recurso de Minification este comportamento pode ocorrer ou não dependendo do cenário.

Se você estiver interessado em conhecer mais e aprender como desenvolver aplicações Web com arquitetura baseada em DDD, aplicando os princípios SOLID, diversos Design Patterns e escrevendo testes de unidade inscreva-se em meu curso:

Vamos continuar a troca de experiências, deixe seu comentário abaixo, se gostou e concorda com o artigo compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis. ;)

Quando estará pronto o novo ASP.NET 5? O que devemos esperar dele?

Publicado em por

Quando estará pronto o novo ASP.NET 5? Essa foi uma das perguntas mais populares na comunidade ASP.NET no último ano. Finalmente agora temos um roadmap até a versão 1.0, acompanhe de perto!

Quando estará pronto o novo ASP.NET 5? Eu respondi milhares de vezes essa pergunta com incerteza, chutes e imprecisão, afinal estamos falando da construção de um novo stack, 12 anos de ASP.NET sendo reescrito do zero pela primeira vez.

ASP.NET 5

Finalmente o time do ASP.NET publicou o roadmap de futuras versões que incluem os próximos betas e a versão 1.0 (RC1).

Eu venho falando do futuro do ASP.NET desde Maio de 2014, em Maio de 2015 realizamos um evento focado no ASP.NET 5 (assista as palestras gratuitamente).

Roadmap das próximas releases

Versão Data de entrega
Beta6 27 Julho 2015 (já disponível)
Beta7 24 Agosto 2015
Beta8 21 Setembro 2015
RC1 Novembro 2015
1.0.0 Primeiro trimestre de 2016

Agora basta acompanhar e aguardar ansiosamente pelas próximas releases.

Observações:

  • O Beta8 será a maior versão entregue, todas as features do RC1 já estarão disponíveis no Beta8.
  • Visual Basic e SignalR 3 não estarão disponíveis antes da versão 1.0, estima-se que serão liberados no terceiro trimestre de 2016.

Tem mais coisas por vir?

Com certeza absoluta digo que sim! Esta será apenas a primeira versão do ASP.NET 5, após entregue a 1.0 com certeza virão muitas outras versões com novas funcionalidades e melhorias.

Como posso contribuir?

Você pode contribuir de muitas maneiras:

  • Desenvolvendo junto com o time e enviando os Pull Requests.
  • Corrigindo Bugs.
  • Avaliando cada versão e reportando os bugs no GitHub do time.
  • Participando das discussões com o time.

Saiba mais detalhes de como poder contribuir neste link.

Já posso usar em produção?

Em produção é por sua conta e risco, nenhum beta deve ser usado em produção, pois existem grandes possibilidades de bugs, falhas e não existe garantia real de funcionamento adequado.

Outra questão é que a manutenção pode ser chata, uma vez que uma nova versão pode quebrar o funcionamento da antiga.

Mas isso não significa que você deve esperar ficar tudo pronto para começar a desenvolver, o quanto antes conhecer a nova plataforma melhor será, existem alguns samples que sempre são atualizados conforme uma nova versão é lançada, baixe os samples e rode a aplicação para analisar e notar as novidades.

Minha sugestão, desenvolva algum aplicativo pessoal para ter uma experiência mais real e saia na frente dos demais 🙂

Quando sai o curso de ASP.NET 5?

Assim que tivermos uma versão estável (sem breaking changes) lançarei o conteúdo do novo curso. Aguardem por novidades.

Resumindo

Apesar de esperarmos pelo novo ASP.NET 5 desde 2014 estamos tratando da construção de um novo stack, logo não é de imaginar que seria entregue em pouco tempo.

Minha opinião é que a partir do segundo semestre de 2016 o ASP.NET 5 começará a ter adesão no desenvolvimento corporativo, pois as empresas não costumam aderir à tecnologias muito novas, geralmente prefere-se ter de 6 meses a 1 ano de mercado para adotar uma nova tecnologia, um tempo razoável para receber as correções e melhorias essenciais.

Acredito que 2017 será um ano de muito ASP.NET 5, com uma maturidade já comprovada no mercado corporativo e muitas adesões.

Caso esteja interessado em aprender a desenvolver aplicações Web Corporativas com as melhores práticas de mercado DDD, Design Patterns, SOLID, performance, escalabilidade e etc, confira meu curso:

Curso ASP.NET MVC – Enterprise Applications

Manterei este post atualizado conforme mudanças ocorrerem.
Caso queira deixar seu feedback utilize os comentários abaixo.

Pense duas vezes antes de utilizar Sessions

Publicado em por

Session é um recurso utilizado em inúmeras situações no ASP.NET, porém já faz algum tempo que seu uso não é mais recomendado, conheça os principais motivos e como você pode substituir as sessions em seu projeto.

Session é um assunto muito abordado em inúmeros fóruns de discussões em todo mundo. Foi introduzido no ASP clássico e sua utilização está presente até os dias de hoje no ASP.NET.

ASP.NET Sessions

Armazenar informações de usuário logado no sistema, itens do carrinho de compras, resultado de uma pesquisa em banco de dados e demais cenários geralmente são resolvidos através do armazenamento em sessions. Por que isso não é recomendado?

O conceito de Web é Stateless

Uma aplicação web não deve manter estado, uma aplicação web deve usar sempre que possível recursos assíncronos no client-side e server-side, isso proporcionará performance pois não satura o pipeline da aplicação e escalabilidade pois não depende de recursos disponíveis em um determinado servidor.

Sessions utilizam a memória do pool do IIS

Por padrão as sessions são armazenadas no pool do IIS e isso é uma péssima opção para armazenar dados de usuários, pois o pool do IIS recicla constantemente e isto está fora do controle do desenvolvedor, por diversos motivos o pool pode ser reciclado e todos os usuários perderão as informações armazenadas, isso é muito frustrante para o usuário da aplicação e nunca deveria acontecer.

Uma solução para isso seria utilizar sessions out-of-proc (armazenando as sessions em um SQL Server ou outro State Server), mas não significa que que é uma boa alternativa, existem alguns problemas nessa abordagem:

  1. Irá custar 2 requisições extras de rede, uma para carregar a session antes do request ser processado e outra para armazenar novamente o estado da session após o request. E isso irá ocorrer a cada request mesmo que não esteja utilizando a session em determinada página.
  2. Não é performático, a cada request a session precisa ser serializada e deserializada, isso irá custar mais recursos de CPU e memória.
  3. Bancos de dados relacionais não são mais rápidos que o acesso de memória, não é performático realizar 2 hits no banco a cada request de cada usuário.
  4. Poderá saturar o pipeline da aplicação, uma vez que um request depende da leitura de um banco de dados para finalizar seu ciclo de vida.

Sessions são de acesso exclusivo

Sessions irão prejudicar a performance de requests concorrentes. Suponha que uma página via AJAX dispare 2 requests para o mesmo usuário, o acesso de leitura da session é exclusivo, logo o ASP.NET irá forçar que o segundo request aguarde enquanto o primeiro faz a leitura da session, isso implica na escalabilidade da aplicação.
Recursos do HTML 5 permitem conexões permanentes (Server Sent Events, WebSockets) isso significa que problemas podem ocorrer no caso de requests concorrentes.

Sessions não são escaláveis

Sessions trabalhando no modo in-proc (habilitado por padrão) irão prejudicar a escalabilidade da aplicação, uma vez que a memória utilizada pela session é de um servidor específico. Suponha que existam N servidores da mesma aplicação que estejam sendo suportados por um load balancing, uma vez que a session foi criada no servidorX a aplicação só funcionará se todos os requests forem redirecionados para o servidorX, existem meios de realizar isto, porém essa abordagem desconfigura o conceito de escalabilidade.

Sessions degradam a performance da aplicação

Em muitas aplicações é possível notar o IIS batendo o topo de utilização de memória, muitas vezes a utilização da memória não é causada pelos recursos do IIS e sim de alocação de dados via sessions. Desenvolvedores realizam uma pesquisa no banco e guardam o resultado numa session para poder reaproveitar a pesquisa, porém quase sempre esquecem de destruir aquela sessão. Essa facilidade que as sessions proveem acaba sendo uma armadilha para boa performance da aplicação uma vez que a memória disponível para rodar a aplicação é dividida e consumida pelas sessions.

Sessions não são necessárias? Como posso substituí-las? Quais recursos utilizar?

Com certeza as sessions não são necessárias e obviamente não devem ser utilizadas pelos motivos apresentados acima. Porém a abordagem para substituir as sessions depende do cenário. Apresentarei algumas possibilidades.

  • Controle de usuários logados, armazenamento de informações de usuários.
    A utilização de Cookies é uma excelente alternativa para persistência de usuários logados, a informação fica no client-side e permite escalabilidade e ao mesmo tempo segurança. Grandes sites como Facebook utilizam Cookies para persistência de usuários.
    Caso queira armazenar informações de usuários no Cookie é possível porém existe uma limitação de tamanho (4K), talvez seja interessante armazenar uma chave no Cookie onde através dela seja possível localizar mais informações em outro recurso de armazenamento.
    O ASP.NET Identity é uma ótima alternativa para esse cenário, ele trabalha com Cookies para persistência do usuário e também com Claims para armazenamento de dados (nome, e-mail, permissões e etc…).

  • Controle de carrinho de compras.
    Carrinho de compras requerem um tratamento especial, pois não importa se a compra foi concluída ou não é sempre importante obter informações sobre carrinhos abandonados para trabalhar na analise dessas informações.
    Minha recomendação é armazenar no banco, em uma tabela destinada para esse tipo de controle, uma vez que o usuário logado retorna ao site é possível oferecer que ele restaure o carrinho abandonado, entre outras possibilidades.
    É possível também controlar o carrinho de usuários não logados através do recurso Anonymous Identification Module do ASP.NET onde é criado um Cookie com um ID único e pode ser recuperado através do Request.AnonymousID.

  • Armazenamento de objetos complexos.
    A solução para isto é cache. Existem diversas soluções para trabalhar com Cache (ASP.NET Data Cache, NCache, Memcached, Redis Cache), um destaque especial para o Redis Cache que se demonstrou uma solução muito eficiente, performática e fácil de implementar, inclusive existe recursos no Azure e AWS para utilização desta ferramenta para cache distribuído e etc.
    O recurso de Cache sempre esteve presente no ASP.NET, sua utilização requer um pouco mais de esforço de implementação do que no uso das sessions, porém convenhamos, programar é um exercício intelectual, pratique isto!

Outras soluções para considerar

Existem outras soluções a serem consideradas, algumas muito simples como Hidden Fields e QueryStrings, onde muitas vezes são o suficiente para resolver o problema.

Outra ótima alternativa no ASP.NET MVC é utilizar ViewData, ViewBag e TempData

Existe uma espécie de armazenamento local (muito maior que um Cookie) chamado WebStorage onde é possível trabalhar com sessionStorage e localStorage, é muito interessante conhecer esse recurso, recomendo a todos que pesquisem sobre o assunto.

Para finalizar…

Elimine a possibilidade de utilizar sessions em sua aplicação, a Web está cada vez mais moderna, escalável e responsiva e é importante tomar decisões que não nos façam andar na contra-mão da Web.

Eu me reuni com outros colegas para bater um papo sobre esse assunto, confira como foi o bate papo.

* Assine meu canal no Youtube 🙂

Vamos continuar com a troca de conhecimentos, utilize o formulário abaixo para postar sua opinião, crítica e lógico seu feedback (adoramos feedback 🙂 ).

Referência

Customizando Nomes de Tabelas e Campos no ASP.NET Identity

Publicado em por

O ASP.NET Identity possui um padrão de nomenclatura para suas tabelas e campos, muitas vezes é necessário customizar este padrão para atender as necessidades da aplicação, confira como é simples realizar esta tarefa.

Como apresentado aqui algumas vezes, o ASP.NET Identity é um componente muito completo e simples de customizar, ele é escrito baseado no conceito Code-First e sua arquitetura é bem aberta possibilitando a customização de funcionalidades, comportamentos e até mesmo fonte de dados.

As tabelas que o ASP.NET Identity cria automaticamente segue o mesmo processo de qualquer desenvolvimento Code-First, permitindo que o desenvolvedor mapeie na configuração do DbContext toda a modelagem da base que será criada.

Vamos abordar de forma muito simples e pontual como realizar este processo partindo do pré-suposto que sua aplicação foi criada com base no template de aplicação ASP.NET MVC já com o ASP.NET Identity configurado. Independente deste fato, o que é realmente necessário fazer é editar o contexto do ASP.NET Identity.

Uma dica válida para qualquer situação é manter sempre o contexto do ASP.NET Identity separado do contexto da aplicação.

Iremos trabalhar também com a hipótese de customização do IdentityUser através de sua classe derivada ApplicationUser. Vamos ao código.

public class ApplicationUser : IdentityUser
{
    public string Apelido { get; set; }
}

public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
    public ApplicationDbContext()
        : base("DefaultConnection")
    {
    }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        base.OnModelCreating(modelBuilder);

        modelBuilder.Entity<IdentityUser>()
            .ToTable("Usuarios")
            .Property(p => p.Id)
            .HasColumnName("UsuarioId");

        modelBuilder.Entity<ApplicationUser>()
            .ToTable("Usuarios")
            .Property(p => p.Id)
            .HasColumnName("UsuarioId");

        modelBuilder.Entity<IdentityUserRole>()
            .ToTable("UsuarioPapel");

        modelBuilder.Entity<IdentityUserLogin>()
            .ToTable("Logins");

        modelBuilder.Entity<IdentityUserClaim>()
            .ToTable("Claims");

        modelBuilder.Entity<IdentityRole>()
            .ToTable("Papeis");
    }
}

Na classe ApplicationUser realizamos uma pequena customização adicionando um novo campo (Apelido), apenas para enfatizar a situação.

Na classe ApplicationDbContext repare que ela herda de IdentityDbContext, que é a real classe de contexto do ASP.NET Identity onde ela internamente herda de DbContext.

A ideia de existir a classe ApplicationDbContext é justamente fornecer um contexto para customização, uma vez que a classe IdentityDbContext faz parte dos assemblies do ASP.NET Identity e não é possível ser alterada.

Baseado no conceito da herança o que basicamente fizemos foi sobrescrever o método OnModelCreating da classe base para alterarmos os padrões de nomenclatura. Utilizamos Fluent API para realizar esse mapeamento trocando os nomes das tabelas e campos.

Essa troca não impacta no funcionamento interno do ASP.NET Identity, pois as classes internas permanecem intactas, apenas o mapeamento do modelo objeto / relacional foi modificado e a aplicação irá seguir o que a modelagem manda.


modelBuilder.Entity<IdentityUser>()
    .ToTable("Usuarios")
    .Property(p => p.Id)
    .HasColumnName("UsuarioId");

modelBuilder.Entity<ApplicationUser>()
    .ToTable("Usuarios")
    .Property(p => p.Id)
    .HasColumnName("UsuarioId");

Repare que as duas classes (IdentityUser, ApplicationUser) foram mapeadas para mesma tabela, pois só assim seria possível mapear a classe de usuários e ao mesmo tempo aplicar as customizações, no final tudo vira uma única tabela com informações de ambas as classes.

ASP.NET Identity Tabelas e Campos Customizados

Detalhes adicionais

  • É possível utilizar todos os recursos do Fluent API nessa abordagem, sendo possível modificar tipo dos campos, inserir índices, criar novos relacionamentos, mapear novas tabelas e etc.
  • É possível realizar todo este mapeamento em uma outra classe e configurar esta classe no contexto (assim como fazemos com as nossas entidades no Fluent API).

Simples?
Agora é possível incorporar o ASP.NET Identity ao seu modelo já existente de base de usuários, a única premissa é que todas as tabelas e campos do ASP.NET Identity sejam representados (mapeados) de alguma forma no banco de dados existente.

Vamos continuar a enriquecer este artigo participando nos comentários abaixo com dúvidas, complementos e feedbacks.

Referências

Este artigo foi escrito durante minha participação na Campus Party 2015 #CPBR8