Participo da comunidade Pantanet e recentemente estou postando artigos sobre Entity Framework 4.1 usando Code First approach.
Vale a pena conferir.
Os links são esses:
Introdução ao ADO.NET Entity Framework 4.1
Introdução ao ADO.NET Entity Framework 4.1 - parte 2: Operações CRUD
Introdução ao ADO.NET Entity Framework 4.1 - parte 3: Mapeamentos complexos
Introdução ao ADO.NET Entity Framework 4.1 - parte 4 - Validação
ADO.NET Entity Framework 4.1 - parte 5 - DbContext Factory e Repository Pattern
ADO.NET Entity Framework - parte 6 - SQL
segunda-feira, 25 de abril de 2011
sábado, 23 de abril de 2011
Teste a performance do .NET em sua máquina
Momento distração.
Recentemente vi um post do Ayende com a seguinte questão: Quantos objetos podem ser criados por segundo? Conversando com os amigos num Pub, houve chutes de 2.000, 5.000 ou 50.000 objetos por segundo. Então ele fez um teste e para a surpresa dele, o resultado foi 7.000.000 de objetos, isso mesmo, 7 milhões de objetos criados em apenas um segundo com uma aplicação Console.
Fiz o mesmo teste e meu resultado foi melhor: 14.106.434, mais de 14 milhões de objetos por segundo.
Faça o teste em sua máquina, crie uma aplicação console e cole esse código:
Faça o teste e comente aqui seu resultado.
Recentemente vi um post do Ayende com a seguinte questão: Quantos objetos podem ser criados por segundo? Conversando com os amigos num Pub, houve chutes de 2.000, 5.000 ou 50.000 objetos por segundo. Então ele fez um teste e para a surpresa dele, o resultado foi 7.000.000 de objetos, isso mesmo, 7 milhões de objetos criados em apenas um segundo com uma aplicação Console.
Fiz o mesmo teste e meu resultado foi melhor: 14.106.434, mais de 14 milhões de objetos por segundo.
Faça o teste em sua máquina, crie uma aplicação console e cole esse código:
public class MyClass
{
public string A;
public int B;
public DateTime C;
}
class Program
{
static void Main(string[] args)
{
while (true)
{
Start();
var k = Console.ReadKey();
if (k.Key != ConsoleKey.Enter) break;
}
}
static void Start()
{
var sp = System.Diagnostics.Stopwatch.StartNew();
int i = 0;
while (sp.ElapsedMilliseconds < 1000)
{
new MyClass();
i++;
}
sp.Stop();
Console.WriteLine("Create {0} in {1}", i, sp.Elapsed);
}
}
Faça o teste e comente aqui seu resultado.
Padrão Façade para trabalhar com Sessions em uma aplicação ASP.NET
Trabalhar com strings hard-coded é algo que pode nos levar a introduzir bugs por falta de atenção e erros de digitação.
É algo que pode ocorrer facilmente quando trabalhamos com Sessions dentro de uma aplicação Asp.NET. Para evitar isso, recomenda-se criar constantes e utilizá-las para gravar ou recuperar os valores armazenados nas Sessions.
Uma alternativa interessante é utilizar uma classe Facade para acessar e gravar os valores das Sessions.
Fiz uma classe chamada SessionVars para isso.
Em qualquer página aspx.cs basta acessar a classe estática e a propriedade desejada para ler o valor ou gravar.
Crie todas as constantes para os nomes das sessions e a propriedade com Get/Set específica.
É algo que pode ocorrer facilmente quando trabalhamos com Sessions dentro de uma aplicação Asp.NET. Para evitar isso, recomenda-se criar constantes e utilizá-las para gravar ou recuperar os valores armazenados nas Sessions.
Uma alternativa interessante é utilizar uma classe Facade para acessar e gravar os valores das Sessions.
Fiz uma classe chamada SessionVars para isso.
public static class SessionVars
{
/*constantes para as Sessions*/
public const string IdUsuario = "IdUsuario";
///
/// Verifica se a Contexto da Session é válido
///
private static bool IsSessionValid
{
get { return HttpContext.Current != null && HttpContext.Current.Session != null; }
}
///
/// Atalho para a Session
///
private static HttpSessionState Session
{
get { return HttpContext.Current.Session; }
}
#region UsuarioId
public static int? UsuarioId
{
get
{
if (IsSessionValid)
{
if (Session[IdUsuario] != null)
{
int idUsuario;
if (Int32.TryParse(Session[IdUsuario].ToString(), out idUsuario))
return idUsuario;
return int.MinValue;
}
}
return null;
}
set
{
if (IsSessionValid)
{
Session[IdUsuario] = value;
}
}
}
#endregion
}
Em qualquer página aspx.cs basta acessar a classe estática e a propriedade desejada para ler o valor ou gravar.
if (SessionVars.UsuarioId != null)
{ //
SessionVars.UsuarioId = 10;
}
Crie todas as constantes para os nomes das sessions e a propriedade com Get/Set específica.
sábado, 16 de abril de 2011
Porquê Silverlight?
Prefácio
Perfil de uma aplicação Desktop
• Executa diretamente no sistema operacional (Delphi/C++/C).
• Ou através de bytecodes interpretados por uma máquina virtual que faz a compilação JIT (Just-In-Time) em tempo de execução (Java/.NET).
• Em ambas situações, toda a camada de apresentação é criada pela aplicação, que busca os dados em um banco de dados local ou em rede.
Perfil de uma aplicação Web
• Utiliza um software do tipo browser que é executado na estação do cliente que envia e recebe requisições http Get/Post a um servidor WEB http.
• O Servidor recebe as requisições e retorna conteúdo (response) que é interpretado pelo navegador que por sua vez cria componentes visuais de acordo com as intruções recebidas.
Perfil de uma aplicação RIA
• Une o melhor dos dois mundos: Executa na estação cliente e distribuíção é através da Web, com atualizações automáticas (ao carregar a página).
• Utiliza um navegador web que atua como um contêiner para a aplicação.
• A executada da aplicação é controlada por um plugin (Flash, Adobe AIR, Java, Silverlight).
• O plugin é executado no sistema operacional.
Experiências
Delphi
Antigamente eu desenvolvia aplicações utilizando Delphi. Fiz sistemas comerciais para desktop, gerando executáveis nativos para a plataforma Windows, acessando banco de dados Interbase/Firebird, Oracle e SQL Server.
• Prós: ótima IDE, facilidade e rapidez para criar uma aplicação, arrastando componentes visuais e configurando suas propriedades. Cumpre o prometido: RAD - rapid application development.
• Contras: As aplicações têm de ser distribuídas e instaladas diretamente nas estações dos clientes, gerando um trabalho extra e dor de cabeça quando era necessário atualizar versões.
Após a versão 8 do Delphi, muitos programadores passaram a desacreditar no futuro da linguagem, com a Borland vendendo o produto para outras empresas, gerando dúvidas e incertezas. Então os desenvolvedores mais prevenidos passaram a estudar uma outra linguagem, como VB.NET, ou migrar para o mundo WEB, como eu fiz.
PHP
Com a popularização da internet, surgiu uma demanda para criação de aplicações específicas para a Web, e com isso, a necessidade de aprender uma linguagem dinâmica. Dominar Html, CSS e Javascript se tornou essencial. O PHP então era a linguagem mais popular para aplicações web e tinha uma ampla comunidade de desenvolvedores.
• Prós: Ampla comunidade, muitos exemplos na internet e muito material disponível.
• Contras: Na minha experiência com PHP, percebi que não havia um padrão a se seguir, o PHP permite criar aplicações mal codificadas, mal escritas, código “macarrão” (html e código php misturado), e por si só não incentiva o programador a aprender a fundo a linguagem, não exige orientação a objetos nem separação de responsabilidades. É uma linguagem de script, interpretada a cada requisição. Para ter algum padrão, é necessário utilizar um framework. Caso contrário, basta copiar e colar qualquer exemplo de código já existente pela internet simplesmente porque alguém já fez e funcionou.
ASP.NET
Essa percepção “negativa” que tenho hoje do PHP aumentou depois que conheci a plataforma .NET, mais especificamente o ASP.NET, a plataforma da Microsoft para a desenvolvimento de aplicações do tipo “WebForms”. As aplicações WebForms abstraem o conceito de programação para a Web onde cada página é uma tela com componentes visuais, similar a um aplicativo desktop, mas renderizando obviamente conteúdo HTML.
• Prós: Separação de código HTML do código da aplicação, linguagem tipada, estática e compilada, não interpretada a cada requisição.
• Contras: O resultado final ainda é a renderização de HTML,CSS e Javascript que será interpretado no navegador, da mesma forma que qualquer linguagem para Web. Para manter o estado dos webforms e seus controles entre as requisições, simulando uma aplicação desktop), cada webform gera um overhead adicional, utilizando artifícios como Sessions, ViewStates, etc.
A web não foi feita para aplicações
A Web inicialmente não previa a execução de aplicações, como no desktop. Na verdade ela previa apenas a apresentação de conteúdo. Com o tempo, a web foi se adaptadando para simular aplicações. O protocolo HTTP evoluiu, depois surgiu o javascript, a seguir os browsers adicionaram suporte a javascript e plugins, etc. E o que temos hoje é uma mistura de várias linguagens e tecnologias trabalhando em conjunto para fornecer ao usuário um ambiente próximo a um aplicativo desktop. O resultado disso é que cada navegador implementa de maneira diferente essas tecnologias, obrigando o desenvolvedor a prever qual browser o usuário está utilizando, e enviar HTML/CSS/JAVASCRIPT específico para tal navegador (Chrome/IE/Firefox/etc).
Com a Web, sua estação de trabalho é um terminal burro
Vamos resumir o ciclo de vida de uma aplicação Web:
1 – Abrir seu navegador preferido.
2 – Informar a URL do site que contém a aplicação que desejada.
3 – O navegador resolve o endereço IP e encontra o servidor web onde a aplicação está hospedada e envia uma requisição do tipo HTTP/Get.
4 – O servidor web, independente da linguagem em que a aplicação foi feita, vai processar a requisição, executar as instruções necessárias e retornar ao navegador um “Response” contendo o HTML gerado pelo servidor.
5 – O navegador recebe a resposta, e partir daí começa a executar todas as instruções que o código HTML determina. Provavelmente isso vai demandar novas requisições para buscar imagens e outros “includes” como javascript/css, num ciclo interno até que finalmente a página possa ser renderizada no navegador.
6 – Esta página que está sendo exibida, pode conter links para outras páginas, nesse caso, ao clicar num link, inicia-se novamente a partir do item 3.
7 – Esta pagina pode conter um formulário que irá submeter dados ao servidor. Nesse caso, o navegador enviará os dados do formulário para o servidor, através de uma requisição do tipo HTTP/POST. O servidor web receberá esse formulário, a aplicação irá tratar as informações, executando as intruções necessárias e devolverá uma resposta novamente ao navegador. Voltamos então a partir do item 4.
Assim, vemos que uma aplicação web se resume a um navegador que envia requisições do tipo GET/POST, em que todas as respostas geradas pelo servidor web incluem novamente todo o conteúdo necessário para se renderizar uma página com imagens, textos a serem exibidos, código javascript, código CSS para formatação de estilos, etc.
O tráfego de informações que é gerado entre uma requisição e outra não se resume somente aos dados utilizados pela aplicação. Por exemplo, se você solicitar 10 vezes a mesma página ao navegador, todo o ciclo será repetido, e nas 10 vezes você receberá todo o mesmo conteúdo novamente.
Por isso costumo entender que de certa maneira, seu computador quando navega na internet é praticamente um terminal burro conectado a um grande mainframe, em que o mainframe processa toda a informação e envia instruções para o cliente exibir as páginas.
Silverlight – Rich Internet Application
Desenvolver com Silverlight é como desenvolver para desktop, utilizando processamento local para formatar telas através de instruções compiladas, com a facilidade de distribuição e atualização que a web oferece. E ainda com a vantagem de reaproveitar todo seu conhecimento em .NET, sem se preocupar com HTML, Javascript e CSS.
Uma aplicação Silverlight incialmente é um objeto carregado dentro de uma página Html. Após esse objeto ser carregado, a aplicação é gerenciada pelo runtime do Silverlight, dentro de uma área isolada e protegida conhecida como sandbox. Nesse ambiente, o silverlight por padrão faz requisições e recebe as respostas através de sua própria implementação de cliente http. Todo o conteúdo necessário para exibir e renderizar as telas e controles não precisam ser carregados ou interpretados novamente, tudo o que a aplicação precisa já está no objeto que foi carregado dentro do navegador. A comunicação com servidores Web se resume apenas a troca de dados, e não mais formatação de telas e regras de negócios.
Portanto, com o Silverlight, você programa praticamente como se programasse para desktop, utilizando uma única linguagem (no meu caso, C#), sendo que a distribuição da aplicação é direto pela Web, unindo o útil ao agradável.
Perfil de uma aplicação Desktop
• Executa diretamente no sistema operacional (Delphi/C++/C).
• Ou através de bytecodes interpretados por uma máquina virtual que faz a compilação JIT (Just-In-Time) em tempo de execução (Java/.NET).
• Em ambas situações, toda a camada de apresentação é criada pela aplicação, que busca os dados em um banco de dados local ou em rede.
Perfil de uma aplicação Web
• Utiliza um software do tipo browser que é executado na estação do cliente que envia e recebe requisições http Get/Post a um servidor WEB http.
• O Servidor recebe as requisições e retorna conteúdo (response) que é interpretado pelo navegador que por sua vez cria componentes visuais de acordo com as intruções recebidas.
Perfil de uma aplicação RIA
• Une o melhor dos dois mundos: Executa na estação cliente e distribuíção é através da Web, com atualizações automáticas (ao carregar a página).
• Utiliza um navegador web que atua como um contêiner para a aplicação.
• A executada da aplicação é controlada por um plugin (Flash, Adobe AIR, Java, Silverlight).
• O plugin é executado no sistema operacional.
Experiências
Delphi
Antigamente eu desenvolvia aplicações utilizando Delphi. Fiz sistemas comerciais para desktop, gerando executáveis nativos para a plataforma Windows, acessando banco de dados Interbase/Firebird, Oracle e SQL Server.
• Prós: ótima IDE, facilidade e rapidez para criar uma aplicação, arrastando componentes visuais e configurando suas propriedades. Cumpre o prometido: RAD - rapid application development.
• Contras: As aplicações têm de ser distribuídas e instaladas diretamente nas estações dos clientes, gerando um trabalho extra e dor de cabeça quando era necessário atualizar versões.
Após a versão 8 do Delphi, muitos programadores passaram a desacreditar no futuro da linguagem, com a Borland vendendo o produto para outras empresas, gerando dúvidas e incertezas. Então os desenvolvedores mais prevenidos passaram a estudar uma outra linguagem, como VB.NET, ou migrar para o mundo WEB, como eu fiz.
PHP
Com a popularização da internet, surgiu uma demanda para criação de aplicações específicas para a Web, e com isso, a necessidade de aprender uma linguagem dinâmica. Dominar Html, CSS e Javascript se tornou essencial. O PHP então era a linguagem mais popular para aplicações web e tinha uma ampla comunidade de desenvolvedores.
• Prós: Ampla comunidade, muitos exemplos na internet e muito material disponível.
• Contras: Na minha experiência com PHP, percebi que não havia um padrão a se seguir, o PHP permite criar aplicações mal codificadas, mal escritas, código “macarrão” (html e código php misturado), e por si só não incentiva o programador a aprender a fundo a linguagem, não exige orientação a objetos nem separação de responsabilidades. É uma linguagem de script, interpretada a cada requisição. Para ter algum padrão, é necessário utilizar um framework. Caso contrário, basta copiar e colar qualquer exemplo de código já existente pela internet simplesmente porque alguém já fez e funcionou.
ASP.NET
Essa percepção “negativa” que tenho hoje do PHP aumentou depois que conheci a plataforma .NET, mais especificamente o ASP.NET, a plataforma da Microsoft para a desenvolvimento de aplicações do tipo “WebForms”. As aplicações WebForms abstraem o conceito de programação para a Web onde cada página é uma tela com componentes visuais, similar a um aplicativo desktop, mas renderizando obviamente conteúdo HTML.
• Prós: Separação de código HTML do código da aplicação, linguagem tipada, estática e compilada, não interpretada a cada requisição.
• Contras: O resultado final ainda é a renderização de HTML,CSS e Javascript que será interpretado no navegador, da mesma forma que qualquer linguagem para Web. Para manter o estado dos webforms e seus controles entre as requisições, simulando uma aplicação desktop), cada webform gera um overhead adicional, utilizando artifícios como Sessions, ViewStates, etc.
A web não foi feita para aplicações
A Web inicialmente não previa a execução de aplicações, como no desktop. Na verdade ela previa apenas a apresentação de conteúdo. Com o tempo, a web foi se adaptadando para simular aplicações. O protocolo HTTP evoluiu, depois surgiu o javascript, a seguir os browsers adicionaram suporte a javascript e plugins, etc. E o que temos hoje é uma mistura de várias linguagens e tecnologias trabalhando em conjunto para fornecer ao usuário um ambiente próximo a um aplicativo desktop. O resultado disso é que cada navegador implementa de maneira diferente essas tecnologias, obrigando o desenvolvedor a prever qual browser o usuário está utilizando, e enviar HTML/CSS/JAVASCRIPT específico para tal navegador (Chrome/IE/Firefox/etc).
Com a Web, sua estação de trabalho é um terminal burro
Vamos resumir o ciclo de vida de uma aplicação Web:
1 – Abrir seu navegador preferido.
2 – Informar a URL do site que contém a aplicação que desejada.
3 – O navegador resolve o endereço IP e encontra o servidor web onde a aplicação está hospedada e envia uma requisição do tipo HTTP/Get.
4 – O servidor web, independente da linguagem em que a aplicação foi feita, vai processar a requisição, executar as instruções necessárias e retornar ao navegador um “Response” contendo o HTML gerado pelo servidor.
5 – O navegador recebe a resposta, e partir daí começa a executar todas as instruções que o código HTML determina. Provavelmente isso vai demandar novas requisições para buscar imagens e outros “includes” como javascript/css, num ciclo interno até que finalmente a página possa ser renderizada no navegador.
6 – Esta página que está sendo exibida, pode conter links para outras páginas, nesse caso, ao clicar num link, inicia-se novamente a partir do item 3.
7 – Esta pagina pode conter um formulário que irá submeter dados ao servidor. Nesse caso, o navegador enviará os dados do formulário para o servidor, através de uma requisição do tipo HTTP/POST. O servidor web receberá esse formulário, a aplicação irá tratar as informações, executando as intruções necessárias e devolverá uma resposta novamente ao navegador. Voltamos então a partir do item 4.
Assim, vemos que uma aplicação web se resume a um navegador que envia requisições do tipo GET/POST, em que todas as respostas geradas pelo servidor web incluem novamente todo o conteúdo necessário para se renderizar uma página com imagens, textos a serem exibidos, código javascript, código CSS para formatação de estilos, etc.
O tráfego de informações que é gerado entre uma requisição e outra não se resume somente aos dados utilizados pela aplicação. Por exemplo, se você solicitar 10 vezes a mesma página ao navegador, todo o ciclo será repetido, e nas 10 vezes você receberá todo o mesmo conteúdo novamente.
Por isso costumo entender que de certa maneira, seu computador quando navega na internet é praticamente um terminal burro conectado a um grande mainframe, em que o mainframe processa toda a informação e envia instruções para o cliente exibir as páginas.
Silverlight – Rich Internet Application
Desenvolver com Silverlight é como desenvolver para desktop, utilizando processamento local para formatar telas através de instruções compiladas, com a facilidade de distribuição e atualização que a web oferece. E ainda com a vantagem de reaproveitar todo seu conhecimento em .NET, sem se preocupar com HTML, Javascript e CSS.
Uma aplicação Silverlight incialmente é um objeto carregado dentro de uma página Html. Após esse objeto ser carregado, a aplicação é gerenciada pelo runtime do Silverlight, dentro de uma área isolada e protegida conhecida como sandbox. Nesse ambiente, o silverlight por padrão faz requisições e recebe as respostas através de sua própria implementação de cliente http. Todo o conteúdo necessário para exibir e renderizar as telas e controles não precisam ser carregados ou interpretados novamente, tudo o que a aplicação precisa já está no objeto que foi carregado dentro do navegador. A comunicação com servidores Web se resume apenas a troca de dados, e não mais formatação de telas e regras de negócios.
Portanto, com o Silverlight, você programa praticamente como se programasse para desktop, utilizando uma única linguagem (no meu caso, C#), sendo que a distribuição da aplicação é direto pela Web, unindo o útil ao agradável.
Assinar:
Postagens (Atom)