2015 foi para mim um ano inesquecível e gostaria de compartilhar com vocês os melhores momentos.
O ano de 2015 está acabando e como de costume quero fazer uma retrospectiva para relembrar e agradecer a todos que fizeram parte deste grande ano.
Primeiramente agradeço a você leitor deste site! Sua presença, feedback e interações tem sido a motivação que desde 2012 eu uso para escrever e criar novos conteúdos.
É muito satisfatório saber que por dia cerca de 2.600 pessoas acessam este site e que de alguma forma estou ajudando estes em suas carreiras, resolução de problemas e etc.
Vamos aos melhores momentos de 2015.
Microsoft MVP Award
Em 2015 eu fui novamente agraciado com o prêmio Microsoft MVP na competência ASP.NET. Fico muito feliz com este prêmio, é muito recompensador ter meu trabalho reconhecido globalmente.
Muitas palestras
Em 2015 eu palestrei em eventos importantes e de prestígio, é sempre um prazer muito grande palestrar para pessoas interessadas. Falar em público é uma arte que estou sempre buscando aperfeiçoar e com certeza pretendo continuar palestrando cada vez mais.
ASP.NET Brasil Conference
O ASP.NET Brasil Conference é o maior evento de ASP.NET da América Latina e reuniu 400 pessoas na última edição. O evento foi um sucesso e eu fico muito satisfeito, pois além de entregar duas palestras eu também sou idealizador / organizador do evento. A edição de 2016 já está em planejamento e esperamos por 600 participantes.
Passei praticamente 4 meses fora de casa viajando a lazer e trabalho, conheci lugares incríveis e aprendi muito! Viajar é muito enriquecedor e eu recomendo a todos como um investimento pessoal a se fazer. Foram tantos lugares que fica até longo enumerar mas ai vai: Internacionais (Berlim, Frankfurt, Hamburg, Munique, Amsterdã, Paris, Versailles, New York, Seattle, Redmond, Bellevue, Mount Rainier, Atlanta) Nacionais (Rio de Janeiro, Belo Horizonte, Natal, Brasília, Mato Grosso do Sul, Goiás, Recife).
MVP Global Summit
Estive em Redmond na sede da Microsoft para o meu segundo MVP Summit e foi uma experiência incrível! Conhecer, aprender e conversar com os engenheiros das tecnologias que usamos diariamente é uma oportunidade ímpar, além de tudo isso a sede da Microsoft é uma cidade de tão grande, vale muito a pena conhecer.
Curso de ASP.NET MVC – Enterprise Applications
Desculpe, nada foi encontrado.
Quem já conhece sabe que é muito mais que um curso de ASP.NET e é por esse motivo que realizei este cursos muitas vezes novamente em 2015 o resultado e os feedbacks tem sido incríveis e muito positivos. 100% de sucesso.
Onde tudo começou, ter um site foi a minha primeira iniciativa de compartilhar meus conteúdos na comunidade técnica. Os resultados tem me surpreendido muito, recebo feedbacks fantásticos, eu mal consigo responder todos em tempo. O site aumentou em 140% o número de visitantes em relação ao ano passado.
Alguns números sobre o site:
Acessos: 955.254 quase um milhão de visitantes em 2015 \o/
Média diária: 2.600
Posts: 117
Horas de vídeo: 25
Comentários: 2.356
O que dizer sobre esse resultado? São tantas coisas, fico muito satisfeito e gostaria de dizer MUITO obrigado a todos que fizeram parte destes números.
AspNetCast
Neste ano surgiu o AspNetCast que é um programa quinzenal online e ao vivo onde falamos sobre tecnologias Microsoft, desenvolvimento Web e claro ASP.NET.
Além de ser um bate papo descontraído é muito divertido transmitir, sempre temos piadas e comentários interessantes além do lado técnico que tem sido bastante elogiado.
Em 2015 gravamos 23 programas e já temos 39.049 visualizações no Youtube.
Vida Política
Depois de muita e decepção e frustração com o atual cenário político do Brasil eu resolvi ajudar de alguma forma, me filiei ao Partido Novo um partido político reconhecido pelo TSE em Setembro de 2015 e que apresenta muitas ideias inovadoras das quais eu me identifico bastante. Não serei candidato a cargos políticos (pelo menos por enquanto) mas estou apoiando o partido e compartilhando os nossos ideais. Somente com pessoas novas, capacitadas e bem intencionadas podemos mudar nosso país. Seja parte da mudança, junte-se a nós!
O que vem pela frente?
Posso adiantar que em 2016 teremos muitas novidades (muitas mesmo), algumas eu ainda nem posso revelar, mas serão muito boas. Continuarei com mais artigos, vídeos, palestras e novos cursos. Possuo alguns projetos pessoais que irei tirar da caixa em 2016 e logo mais compartilharei com todos. No mais, espero continuar viajando bastante e ter mais um ano de experiências incríveis.
2015 foi um ano inesquecível. Muito obrigado por fazer parte dele.
Desejo a todos um excelente 2016! Muito sucesso, estudos, foco e dedicação!
Grande Abraço.
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.
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:
O Windows Service implementa uma forma de receber a comunicação vinda das demais aplicações.
Os Hubs do SignalR no Windows Service distribuem as informações recebidas à todos os clientes conectados.
Os clientes conectados recebem a comunicação em tempo real e se necessário podem encaminhar novas informações para o Windows Service.
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.
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.
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.
E por consequência o código HTML gerado para interpretação do browser não seria o esperado.
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.
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.
O ASP.NET Identity é uma ótima solução para a gestão dos usuários em sua aplicação, porém seu design é diretamente acoplado ao ASP.NET MVC e também devemos evitar de utilizar suas referências no domínio da aplicação.
Desacoplando o ASP.NET Identity. Finalmente após muitos pedidos eu consegui colocar a mão na massa e desenvolver um projeto modelo para ser usado como referência.
Como sabemos o ASP.NET Identity depende diretamente do EF (ou outros), Owin e System.Web, logo todas as implementações do ASP.NET Identity ficam de alguma forma acopladas em nossa camada de apresentação. Quando possuímos uma aplicação onde o usuário é uma peça importante no negócio existe a necessidade de representá-lo na camada de domínio, porém é altamente recomendado que a camada de domínio não conheça tecnologias terceiras (Identity, EF, outros).
Como resolver esse problema?
Foi após alguns estudos que cheguei no modelo que considero ser a “melhor abstração possível”, pois para o ASP.NET Identity funcionar na camada de apresentação é obrigatório levar algumas dependências, porém desde que esteja isolado em outra camada já conseguiremos ótimas boas vantagens.
Aviso: Caso você não conheça o ASP.NET Identity, DDD e Injeção de dependência sugiro que comece pelos tutoriais:
Neste tutorial você encontrará as seguintes tecnologias utilizadas
ASP.NET MVC 5
ASP.NET Identity 2
Entity Framework 6
Fluent API
Injeção de Dependência com Simple Injector
Owin
RestSharp para implementação do Twilio API (SMS)
Existem dois grandes objetivos nesta proposta, o primeiro objetivo é a reutilização, pois com um uma única solução (camada) de gestão de usuários é possível atender N aplicações, facilitando o gerenciamento e manutenção.
O segundo objetivo é permitir que a camada de domínio represente o usuário de forma abstraída, logo não existe referência direta do IdentityUser no domínio, porém é possível consultar os dados de usuário e incluir / modificar as informações salvas.
O primeiro passo é abstrair tudo, mover as dependências do Identity para uma camada isolada, depois injetar no MVC os objetos necessários, para essa implementação eu utilizei o Simple Injector, que como o próprio nome diz, é bem simples, rápido e atendeu bem a necessidade.
Com o Identity isolado e injetado devidamente na camada de apresentação (MVC) basta criar uma camada de acesso a dados que irá fornecer meios do domínio consumir dados do usuário de forma abstraída. A grande sacada está no uso correto do Fluent API e claro muita injeção de dependência.
A solução desde modelo não visa atender completamente a filosofia do DDD, pois procurei simplificar o bastante para deixar simples de modificar, por exemplo adicionando uma camada de Application. Portanto quem utilizar esta arquitetura deve estar ciente que algumas coisas a mais ainda precisam ser feitas.
Gostaria de ressaltar também que o template de projeto ASP.NET MVC que o Visual Studio fornece possui vários problemas de design de código. As controllers de Account e Manage do usuário precisaram ser parcialmente re-escritas para atender a injeção do Identity, problemas como mais de um construtor público e utilização do pattern (ou anti pattern?) Service Locator foram encontrados e retirados.
Para quem quiser acompanhar em detalhes técnicos toda a implementação dessa solução eu preparei o vídeo a seguir.
* Assine meu canal no Youtube 🙂
O código fonte desta solução está disponível no GitHub, caso queira propor alguma melhoria faça um Pull Request, será muito bem recebido.
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.
O dia do programador é celebrado no 256º dia do ano (13 de setembro ou 12 de setembro nos anos bissextos). O número 256 foi escolhido para esta data porque 256 é o número de valores distintos que podem ser representados com um byte de oito bits. Além disso, 256 em hexadecimal é 100 (0x100), e é a maior potência de 2 abaixo de 365 (o número de dias em um ano).
Feliz dia do Programador! Sim nós temos um dia oficial e não podemos deixar passar sem comemorar e cumprimentar os colegas de profissão.
Ser programador é possuir a capacidade de mudar o mundo. Não preciso ir muito longe para completar esse raciocínio, basta lembrarmos de programadores como (Gates, Zuckerberg, Torvalds) entre tantos outros que através de suas paixões realizaram seus sonhos e mudaram a forma de como o mundo funciona.
Ser programador é trabalhar movido pela paixão em usar todo nosso potencial intelectual e criatividade para solucionar problemas existentes e criar novas soluções que facilitam a vida das pessoas.
Ser programador é viver a vida comprometido em estudar para sempre e estar constantemente atualizado. Trocar o dia pela noite, não dormir enquanto não encontrar a solução de um problema (ou simplesmente descobrir a solução enquanto dorme e levantar novamente para implementar e ver se funciona).
Eu não acredito que alguém nasce com dons para programação, a arte de programar é desenvolvida com muito estudo, foco e determinação, muitos exercícios para fortalecer a lógica. Certamente quem tem uma mente mais direcionada ao raciocínio lógico terá mais facilidade para aprender, porém programar é antes de tudo o resultado de muito estudo.
Atualmente tudo com o que nos relacionamos no dia-a-dia envolveu o trabalho de um programador. Sites, redes sociais, sistemas operacionais, aplicativos para computador e celular, dispositivos eletrônicos, transportes e até mesmo nossos eletrodomésticos! Tudo tem em sua base o trabalho de um programador.
É uma das profissões mais prósperas do mundo, inclusive o mundo precisa de muito mais programadores do que existem hoje, com o rápido crescimento e avanço das tecnologias os programadores são peças cada vez mais fundamentais para o funcionamento deste ecossistema.
Existem muitas piadas relacionadas aos programadores, sobre não ter vida social, ganhar pouco dinheiro, trabalhar demais. Eu vejo isso como simples piadas, ser programador não é mais uma atividade para nerds e seres excluídos socialmente como retratam muitas vezes. É possível ser programador e ter uma ótima qualidade de vida, tempo disponível e claro um excelente salário, tudo depende de estudo, foco e determinação (e obviamente de boas escolhas).
Ser programador é poder trabalhar quando quer, a hora que quiser, em qual país quiser. É poder trabalhar em grandes empresas ou simplesmente ser o seu próprio chefe. Programadores são universais, podemos trabalhar em um país e morar em outro, podemos planejar nossa vida com uma liberdade que não existe em muitas profissões e atividades.
Então sinta-se uma pessoa de sorte, pois você é um programador!
Em alguns anos o número de vagas de trabalho abertas para programadores será o dobro do número de programadores existentes. Se você conhece alguém que se interesse por esta área o incentive a entrar! Se você já um programador não deixe nunca de estudar, sua carreira e meta de vida só dependem dos seus esforços!
Gostaria de oferecer uma ajuda na sua educação, estou dando 20% de desconto em todos os meus cursos até dia 20/09/19. Aproveite 🙂
Um abraço a todos programadores e estudantes. Juntos desenvolveremos um mundo melhor 🙂
Quem nunca disse ou ouviu isso? Vamos entender os motivos por trás dessa icônica frase.
Vamos precisar reescrever essa aplicação do zero! É a frase de rendição, é sinal que as coisas foram para o caminho errado. Dias, meses, anos de desenvolvimento que serão jogados fora por falta de um bom planejamento.
Quando chegamos nessa situação geralmente estamos diante de alguns dos cenários a seguir:
A tecnologia da aplicação é antiga demais e os novos recursos demandam mais tecnologia.
A arquitetura da aplicação é uma engenhoca complexa e sem sentido.
Devido a diversas implementações e manutenções do passado feitas de forma irresponsável ou sem padrão a aplicação se tornou a famosa “colcha de retalhos”, qualquer tipo de mudança é sofrível e demorada.
A cada mudança surgem diversos bugs em todas as partes da aplicação, pois existe muito acoplamento entre suas divisões, “tudo está acoplado com tudo”.
O time que trabalha na aplicação atualmente não concorda com a forma com que foi escrita e não está satisfeito em trabalhar nela.
Algumas situações muitas vezes não possuem uma escapatória, por exemplo o envelhecimento natural da aplicação. É muito caro manter uma aplicação sempre alinhada com a última versão da tecnologia, logo, algumas vezes prefere-se optar por saltos (atualizar a cada X tempo) ou simplesmente reescreve-la depois de alguns anos.
O cenário de envelhecimento da aplicação é um dos menores, geralmente a aplicação morre muito antes da hora. Eu trabalhei em uma empresa onde assisti a mesma aplicação ser reescrita 1 vez ao ano durante 3 anos. O que ocorre de tão errado assim?
Existem muitos motivos para tudo dar errado:
Equipe tecnicamente despreparada.
Falta de um líder técnico ou arquiteto que conduza o time e evite a deformação da aplicação.
Escopo mal planejado, falta de entendimento da entrega.
Prazo mal calculado.
Falta de visão. Típico caso do sisteminha de cadastro que virou um “ERP”.
Gestor de equipe que pula etapas e/ou não valoriza (não conhece) boas práticas, impondo uma metodologia que funciona apenas na teoria dele.
Motivos para dar errado são muitos, fazer software da forma correta é infinitamente mais complexo que simplesmente entregar software. É necessário ter uma boa equipe, um bom líder e um bom gestor.
Software é um bem durável assim como uma TV, Geladeira ou Carro, paga-se muito caro para desenvolve-lo e muito caro para mante-lo. A diferença é que o software precisa ser flexível e adaptar-se às constantes mudanças de escopo, logo não pode possuir uma engenharia fechada como uma TV e geralmente é ai onde mora a maioria dos problemas.
Para garantir um bom funcionamento da aplicação de forma que ela se adapte às diversas mudanças de escopo com o mínimo de esforço necessário e sem gerar outros problemas secundários, é preciso projetar a aplicação, não basta simplesmente escrever a aplicação e entregar.
Alguns pontos importantes devem sempre ser abordados:
Processo
Processo de desenvolvimento de software é um tema extenso demais, portanto deixarei apenas alguns pontos em destaque que devem ser levados bastante em consideração.
Processo de desenvolvimento de software é um processo diferente de outros, porém infelizmente ainda existem gestores que imaginam que desenvolver uma aplicação é o mesmo que construir um prédio, um navio ou um avião.
Durante a construção de um prédio com a obra em estágio avançado é praticamente impossível aplicar mudanças que mudam o aspecto do projeto, existe uma engenharia fechada e projetada para ser daquela forma, qualquer mudança poderia impactar em ter que iniciar novamente do zero.
Uma aplicação bem projetada deve ser flexível e estar aberta para mudanças de escopo com menor esforço necessário, portanto não devemos nos apegar em simplesmente entregar o que foi inicialmente levantado.
Uma das formas mais práticas de atender a necessidade do cliente é a entrega contínua, releases parciais para acompanhamento e feedback do cliente, é muito mais fácil ajustar uma mudança de escopo com a aplicação 30% desenvolvida do que se estivesse 100%.
Focar em definir bem os requisitos das entregas mais próximas é muito melhor que tentar documentar 100% do projeto antes mesmo de iniciar a codificação.
Sim estamos falando de metodologias ágeis como o Scrum por exemplo, um projeto de software é diferente de um projeto de construção civil e merece um framework de desenvolvimento interativo e incremental.
Planejamento
É necessário analisar qual será o porte da aplicação, não existe uma receita para todo tipo de aplicação, se ela for grande e complexa é necessário abordar alguma prática de arquitetura, por exemplo DDD.
Se a aplicação for simples é necessário evitar exageros e complexidades que não beneficiam as funcionalidades da aplicação.
Orientações como o KISS e o YAGNI dizem para evitar os exageros e manter a aplicação simples, é fato, mas isso não significa que você deve fazer tudo na camada de apresentação por exemplo, uma mínima divisão de responsabilidades é essencial para a qualidade de qualquer tipo de aplicação.
Arquitetura
Arquitetura é a base de tudo, é muito importante fazer a escolha ideal e evitar a famosa “arquitetura BOLOVO” de 3 camadas (Modelo, Business e DataAccess).
Hoje em dia está claro que apesar de funcionar e ser simples esse modelo traz muitos problemas.
É muito importante ter uma pessoa no papel de arquiteto, que conheça diversas estratégias de arquitetura e saiba aplicar bem os inúmeros patterns disponíveis.
Uma vez que possui sua arquitetura definida a aplicação deve se manter dentro do aspecto da arquitetura original, corromper camadas para acessar mais facilmente o banco ou para resolver mais rapidamente um problema pode ser considerado um crime.
Descaracterizar a arquitetura de uma aplicação é o primeiro passo para a famosa “Colcha de Retalhos”. O arquiteto ou líder técnico deve ser responsável por garantir que a arquitetura não esteja sendo corrompida e que seja mantida dentro de sua proposta em toda extensão da aplicação.
Codificação
Mesmo com uma arquitetura definida a tarefa de codificação ainda é complexa e não existem motivos para ser diferente. Codificar exige muitas habilidades além do próprio conhecimento da linguagem e plataforma.
É importantíssimo valorizar os princípios básicos da orientação à objetos como o SOLID que apesar de ser básico podemos dizer que grande parte dos desenvolvedores ainda não sabem como escrever código usando injeção de dependência (DIP) para evitar o alto acoplamento. Realizam heranças sem sentido apenas pelo fato de um objeto herdar hierarquicamente de outro no mundo real. Deixam o princípio de responsabilidade única de lado (SRP) e não criam classes extensíveis (OCP) deixando o código sempre aberto.
Entre outros pontos falhos não citados, os mencionados acima já são responsáveis por grande parte dos problemas existentes em nossas aplicações. Codificar não é uma tarefa menos grandiosa como arquitetar um sistema, pelo contrário, precisamos valorizar mais o programador que possui esses conhecimentos.
Padrões de codificação como nomenclaturas e regras são importantes para manter a expressividade e facilidade de leitura do código. Antigamente programadores se gabavam por fazer códigos que somente eles entendiam, isso não deve existir, o código é uma série de instruções que devem ser de leitura clara e leve, muitas vezes dispensando uma documentação própria.
Uma técnica de codificação que vem ganhando popularidade é o TDD, apesar do TDD ter seu nome diretamente relacionado com testes o TDD na verdade é sobre codificação, os testes que guiam a codificação via TDD servem para garantir a qualidade do código que no final também garantem a sua testabilidade.
Testes
Testes é um assunto complexo, primeiramente devemos entender que teste de software não é apenas rodar a aplicação e ver se tudo está funcionando.
Existe mais de um tipo de teste, podendo ser de unidade, de integração e etc.
Os testes de unidade são necessários quase sempre, podemos dizer que 80% de cobertura de código através dos testes é um resultado bem positivo. Testes de unidade são muito importantes para garantir a boa escrita do código e validar a sua funcionalidade durante o desenvolvimento. Se durante a codificação um teste falhar pode significar que alguma coisa foi feita de forma que o código deixou de funcionar como deveria, logo evitará o deploy prematuro em produção e que o cliente tenha a infelicidade de descobrir um novo bug.
Descobrir um bug em tempo de codificação é N vezes mais barato que descobrir um bug em produção, evita retrabalho, horas extras, replanejamento de deploy, insatisfação com o cliente etc.
Muitas pessoas alegam que escrever testes de unidade fazem o software custar mais caro, pois aumenta mais o esforço de codificação. Isto parece fazer sentido se olharmos apenas no sentido da entrega, mas mesmo assim não faz. Os testes exigem mais esforço de codificação, porém conforme a cobertura de testes aumenta a velocidade de entrega aumenta junto, pois os testes facilitam muito as futuras modificações.
Contabilizar o esforço apenas baseado na entrega é uma falha. Devemos sempre levar em conta a manutenção e evolução, e quando falhamos nesse aspecto estamos iniciando o ponto onde a aplicação vai se tornar cada vez mais complexa para se testar, evoluir, receber manutenções.
Costumo dizer que programamos uma aplicação durante 6 meses e a mantemos durante 3 anos ou mais, sendo assim nosso foco deveria ser na manutenção e evolução e não apenas na entrega. Todo lucro obtido numa entrega mal planejada será perdido durante a manutenção, podendo inclusive chegar ao negativo, e esse é um dos principais motivos que levam diversos projetos falharem e se transformarem em prejuízo quando deveriam continuar gerando lucros.
Os testes de unidade são de responsabilidade do desenvolvedor, os testes de integração e etc podem ser de responsabilidade de um profissional de qualidade ou simplesmente de toda a equipe (equipes multidisciplinares sabem codificar e testar).
Testes de unidade garantem a qualidade de escrita do código e de sua funcionalidade, um código que não está coberto por testes não é um código confiável. Não existe processo ágil de desenvolvimento sem testes, portanto está claro. Testar é preciso!
Quando tudo deu errado.
O planejamento da aplicação não foi bem feito, a arquitetura não foi bem desenhada para atender o propósito da aplicação, a codificação está estruturada, acoplada e sem padrão, não existem testes de unidade e realizar qualquer manutenção significa alterar diversas partes do código e ser obrigado a testar manualmente todas funcionalidades de ponta a ponta, mesmo assim sempre escapando alguns novos bugs.
As noites são longas quando é necessária alguma manutenção, o deploy em produção é uma aventura preocupante, a satisfação de trabalhar no projeto já não existe mais e a pressão não vale a pena.
O gestor do projeto não aceita mais tantos bugs e exige mais assertividade, questionando inclusive a capacidade técnica da equipe, o cliente não aceita mais os prazos para ajustes simples e não quer pagar a mais por isso também.
Não dá mais! Vamos precisar reescrever essa aplicação do zero.
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 essa mensagem para o máximo de pessoas possíveis. 😉
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.
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:
O ASP.NET Brasil Conference 2015 foi um grande sucesso. 400 participantes, palestras de alto nível e muitos prêmios sorteados. Acompanhe as gravações.
Gostaria de agradecer aos presentes no ASP.NET Brasil Conference, neste grande evento eu atuei como organizador e fiquei extremamente satisfeito com o resultado e o feedback dos participantes.
Evidentemente eu gostaria de realizar um evento para 5.000, 10.000 pessoas mas por diversas questões é um número muito grande para se trabalhar. Mas quem não pode ir ora por não encontrar mais ingressos disponíveis ora por não ter tido oportunidade não precisa se chatear, nosso conteúdo foi 100% gravado e está sendo distribuído de forma gratuita.
Caso esteja interessado em aprender a desenvolver aplicações Web Corporativas com as melhores práticas de mercado DDD, Patterns, SOLID e etc, confira meu curso:
Vivemos um novo momento no desenvolvimento de software onde a abstração do relacionamento da aplicação com o banco de dados tende a ser cada vez maior, hoje o banco de dados não é mais o centro da aplicação.
Este é um assunto muito polêmico e que interessa tanto aos desenvolvedores de software como aos especialistas em banco de dados (DBA’s e etc).
Quem desenvolve software a mais de 5 anos pôde acompanhar uma nova tendência crescendo rapidamente, que é a forma na qual a aplicação se relaciona com o banco de dados. Infelizmente ainda hoje os profissionais aprendem na faculdade ou no ambiente de trabalho um modelo de desenvolvimento que já está no passado, e é esta minha motivação em escrever este artigo.
Há muitos anos nosso processo de desenvolvimento vem ocorrendo de uma maneira clássica (e hoje em dia inadequada), o DBA desenvolve toda a modelagem do banco de dados elencando as entidades (tabelas) e seus relacionamentos conforme a necessidade e seu próprio entendimento do negócio, após isso aplicam-se as regras de normalização, valida-se o MER (modelo-entidade-relacional) e pronto! Basta escrever as Stored Procedures, Triggers e Views com as regras de negócio e entregar para o desenvolvedor desenvolver a aplicação que vai consumir o banco.
Então a aplicação é uma camada “casca” que envolve o banco de dados, consumindo e inserindo novas informações?
Isso parece meio ridículo para um desenvolvedor de software hoje em dia, mas esse modelo “3 camadas” já foi muito (e ainda é) pregado e defendido por ai. A primeira camada é a UI (user interface) a segunda é o “core” da aplicação que consome diretamente o banco de dados e a terceira é o próprio banco.
Um dos pontos muito defendidos nessa distribuição de 3 camadas era que a máquina do usuário não precisava possuir muito recurso computacional e nem conhecer as regras de negócio uma vez que poderia haver uma engenharia reversa da aplicação instalada.
Esse argumento não é mais válido hoje em dia dado a infinidade de recursos computacionais e tecnológicos que possuímos (Web, SOA, etc.).
Um outro forte argumento para a centralização no banco de dados é de que o servidor de banco de dados é uma máquina muito rica em recursos computacionais e consegue processar as regras de negócio com mais velocidade do que um servidor de aplicação.
Esse argumento além de passado ocasiona diversos problemas que serão abordados a seguir.
Regras de negócio em Stored Procedures é uma má prática
Poderia elencar diversos adjetivos para a utilização de regras de negócios em stored procedures, porém vamos considerar apenas uma má prática que deve ser evitada a todo custo. Listarei alguns problemas/dificuldades muito frequentes com a adoção desta prática:
A linguagem TSQL (Transact SQL) é muito limitada em comparação as linguagens atuais, requer mais código e dificulta a interpretação/entendimento, requer mais esforço aumentando o tempo de codificação.
É muito difícil escrever testes de unidade para regras de negócio em stored procedures.
O mecanismo que gera o plano de execução para as stored procedures não trabalha bem com condições (IF, Case, etc) podendo ocasionar uma lentidão muito grande ao chamar uma stored procedure com diversos fluxos.
Quebra o conceito de responsabilidade única, a regra pode estar parte no banco, parte na stored procedure. Além de aumentar o esforço na analise e detecção de problemas.
Estimula a escrita de milhares de linhas de código em apenas uma store procedure, algumas delas com mais de 4.000 linhas são bem fáceis de se encontrar por ai. O esforço de manutenção é centenas de vezes maior, além do risco de introdução de novos bugs.
Existem diversos contras além dos listados, porém estes citados são base de muitos problemas comuns no dia a dia. Não entenda que as stored procedures não devem ser utilizadas, até devem dependendo do cenário, porém sem regras de negócio.
E sobre o uso das Triggers?
Dentre um determinado conjunto de decisões que podem ocasionar sérios problemas entre aplicação e banco de dados, uma delas é o uso de Triggers.
Triggers podem ser úteis em alguns cenários, porém existem outras opções mais eficazes. Não há nada que uma trigger faça que não possa ser substituído por outro recurso (externo do controle do banco de dados) e que funcione de forma mais controlada, elegante, e lógico, testável.
O servidor de banco de dados é muito mais rápido que o servidor de aplicação
Fato! E deve ser mesmo, pois a questão é, quantos bancos de dados é possível escalar lado a lado? Manter bancos de dados sincronizados não é uma tarefa simples e não custa nada barato. Na maioria das aplicações existe um único banco de dados ativo (outros de contingência) e N servidores de aplicação consumindo o mesmo banco. É muito mais fácil escalar o servidor de aplicação e muito mais barato (basta conferir os valores de licenciamento de um SGBD). A própria aplicação de atualizações nos servidores de aplicação é muito mais simples do que no servidor de banco de dados.
Não é por que o banco de dados tem capacidade computacional superior que ele deve ser responsável pelo negócio em si, o banco de dados é um repositório de dados, ele deve ter alta disponibilidade para entregar com a maior velocidade possível as consultas. Utilizar os recursos computacionais do banco de dados para validar o negócio é queimar dinheiro e ocasionar problemas de performance.
O mundo é muito maior que o relacionamento entre tabelas no banco de dados
Podemos dizer que hoje o modelo de programação orientada a objetos dominou o mercado de software, sim existem ainda outros modelos (procedural, funcional, etc) porém a grande parte do mercado aderiu a famosa OOP.
Programar orientado a objetos é uma forma muito mais rica de mapear o mundo real do que as simples formas de relacionamento presentes de banco de dados relacionais, existem bancos de dados NoSQL, orientados a objetos, baseados em grafos e etc, porém não são populares como os relacionais (MSSQL, Oracle, MySQL, etc).
Se a orientação a objetos é uma forma de mapeamento mais rica que o modelo entidade-relacionamento dos bancos de dados, deveríamos então modelar nossa aplicação baseadas em classes e não em tabelas? Exato!
Partindo desta decisão como ficaria o relacionamento de uma aplicação orientada a objetos consumindo um banco de dados relacional?
Alguém já resolveu esse problema faz muitos anos, são os famosos ORM’s
O ORM (Object-relational mapping) faz justamente este trabalho, mapeando entidades de software (classes) para entidades de bancos de dados (tabelas). Com isto é possível que uma única tabela de banco de dados seja representada por N classes e vice-versa.
Os ORM’s abstraem o banco de dados
Abstrair o banco de dados significa parar de se preocupar com a modelagem do banco na hora de modelar o sistema, a modelagem pode ser feita em UML utilizando diagramas de classes entre outros diversos tipos de diagramas, no final o mapeamento das suas entidades de software estarão muito melhores definidas do que se tivessem sido feitas com base no MER de banco de dados relacionais.
O ORM cuida para que o seu mapeamento orientado a objetos faça sentido com o mapeamento entidade relacionamento.
A abstração não para por ai, através dos ORM’s é possível desligar a dependência tecnológica do banco de dados na aplicação, a aplicação não estará mais acoplada a uma tecnologia de banco de dados, trocar um banco de dados de uma aplicação não é nada trivial, porém se abstrairmos/desacoplarmos a aplicação do banco através do uso de um ORM essa tarefa seria infinitamente mais fácil.
Produtividade! Desenvolvedores não precisam codificar todas as consultas em linguagem TSQL, o ORM promove um novo modelo de consumo do banco de dados, o ORM fica encarregado de gerar as queries para comunicar-se com o banco, quando necessário o desenvolvedor pode fornecer uma query específica para ser utilizada no banco através do ORM.
Escreva sua aplicação e ganhe banco de dados
O modelo Code First já está presente faz alguns anos no mercado e seu uso vem crescendo de forma gigantesca, uma vez que possuímos o ORM para abstrair o banco de dados, por que não deixar com ele também a criação e atualização do banco?
Isso mesmo, basta mapear todo seu universo do negócio em classes, escrevê-las e no final gerar o banco de dados que se adeque a modelagem da aplicação. Afinal o banco de dados é um repositório de dados.
O Entity Framework em sua nova versão (7) trabalhará apenas com o modelo Code First, para desenvolvimento de aplicações com base de dados já existentes será possível utilizar os recursos de engenharia reversa. A atualização do banco pode ser feita também através de recursos como Migrations.
E o DBA? Morreu?
Muito pelo contrário! Quem vai garantir o perfeito funcionamento do banco? Backup, segurança, implementações de recursos de performance, acompanhar problemas em tempo real e prover rápidas soluções, dividir tabelas especiais em discos independentes e etc… Isso tudo é trabalho do DBA.
Uma coisa que está errada faz muito tempo é que a modelagem de banco de dados é de responsabilidade do DBA, criar mais um campo na tabela, escrever uma stored procedure e outras atividades desse tipo eram de decisão do DBA. Quantas vezes um desenvolvedor já precisou explicar para o DBA o por que precisava de um campo a mais numa tabela, ou por que uma stored procedure devia ser alterada. Isso não faz sentido.
Em um time de desenvolvimento o número de DBA’s é muito menor do que o número de desenvolvedores, nesse cenário o DBA iria trabalhar apenas para atender as necessidades dos desenvolvedores, deixar estas responsabilidades com o DBA é impedir de que ele faça seu real trabalho que é manter o banco de dados altamente disponível utilizando todo seu potencial.
Alguns DBA’s são contra o uso de ORM’s por que ferem seu sentimento de responsabilidade por algo que não deveria ser de sua responsabilidade. Os ORM’s aos poucos estão dando de volta aos desenvolvedores o que era para ser seu desde sempre, o domínio da modelagem e desenvolvimento da aplicação. E claro, numa situação de dúvida não custa nada perguntar a opinião do DBA.
Não importa onde estão os dados
Hoje os bancos de dados relacionais não são a única fonte de dados, os dados podem estar disponíveis através do consumo de serviços (SOA, WCF, WebAPI), podem estar em bancos NoSQL (MongoDB, Redis, etc), podem estar em bancos de dados In-Memory (Hekaton, MemSQL) ou simplesmente sendo abstraídos pelo seu ORM.
Por exemplo no DDD (Domain-Driven-Design) temos uma abstração tão grande que realmente não importa de onde vem os dados, a aplicação não fica dependente disto (apenas na camada de configuração de dados). É neste sentido que devemos caminhar, escrever aplicações focadas no domínio do negócio, que por si próprias saibam resolver qualquer problema e que possam ser expostas através de serviços para que sejam consumidas através de qualquer plataforma, device e etc…
Hoje todo gestor de desenvolvimento fala e se interessa por métodos ágeis, não existe agilidade sem teste, testes de unidade e testes de integração, abstrair o banco de dados é uma forma de promover a possibilidade dos testes, da análise do código escrito, da validação da regra de negócio, poder realizar um Mock de um repositório sem bater no banco de dados e etc. Num mundo onde dependemos de um banco de dados presente para realizar um teste de unidade, com certeza esse não é um mundo muito ágil.
Os banco de dados relacionais irão tornar-se obsoletos no futuro?
Essa mesma pergunta foi feita quando surgiram os bancos de dados orientados a objetos, bancos de dados de grafos, NoSQL.
Os bancos de dados relacionais estão acompanhando a evolução tecnológica, tornando-se cada vez mais performáticos, com mais recursos para alta disponibilidade e etc, porém de outro lado estão surgindo conceitos como Big Data que impulsiona a utilização de bancos NoSQL, redes sociais que utilizam muito o conceito de banco de dados de grafos, entre diversas novidades que não param de surgir.
Acredito que cada modelo de aplicação possui um tipo (ou tipos) de banco de dados que melhor atendem o cenário. O importante é saber como e quando utilizar cada um deles.
Para finalizar
O mundo muda constantemente e cada vez mais rápido, conceitos aprendidos na faculdade anos atrás ou até mesmo hoje em dia podem estar em constante desuso. Políticas antigas de empresas ou até mesmo profissionais conservadores de padrões ultrapassados são muito comuns no nosso mercado.
É importante estar antenado e preparado para quebrar paradigmas, pesquisar e aprofundar-se em melhores práticas de desenvolvimento de software, sempre prezando reusabilidade, performance, escalabilidade e com certeza qualidade garantida por testes de unidade.
Além deste artigo eu participei de um bate papo muito construtivo sobre este assunto com meus colegas do AspNetCast, assista o vídeo também.
* Assine meu canal no Youtube
Vamos continuar a troca de conhecimentos, deixe seu comentário abaixo, pode ser dúvida, elogio ou sua opinião que é sempre muito importante 😉
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.
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:
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.
Não é performático, a cada request a session precisa ser serializada e deserializada, isso irá custar mais recursos de CPU e memória.
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.
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.
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 🙂 ).
