Desafio III - Membros Static

08/14/2009 11:24:00 By Felipe Pessoto

As seguintes classes geram o mesmo resultado? Se não, por quê?

public class A
{
     public static string X = "A";
}

public class A
{
     public static string X;

     static A()
     {
          X = "A";
     }
}




Teoricamente deveriam ser iguais, mas a segunda classe é equivalente à:

public class A
{
     public static string X = "A";

     static A()
     {
     }
}



A diferença está existência ou não do construtor. Quando não há construtor a classe é marcada como beforefieldinit, fazendo com que o type initializer seja chamado antes mesmo de qualquer referência à algum membro da classe.

Podemos perceber isso com o seguinte código:

class Program
{
     static void Main(string[] args)
     {
          Console.WriteLine("Iniciando");
          A.Escrever("Escrever");
          Console.WriteLine("Depois de escrever");
          string y = A.X;
          Console.WriteLine("Depois de acessar o campo X");

          Console.ReadKey();
     }
}

public class A
{
     public static string X = Escrever("X (Type Initializer)");

     public static string Escrever(string s)
     {
          Console.WriteLine(s);
          return s;
     }
}



Antes de qualquer coisa, o tipo já é inicializado. Mas se você criar um construtor, mesmo que vazio, a ordem das chamadas vai mudar.

O Type Initializer só é executado antes da primeira referência ao tipo. No caso antes do A.Escrever("Escrever").

Curioso, e pode gerar um comportamento inesperado.

Associando entidades por ID no Entity Framework

06/17/2009 14:33:00 By Felipe Pessoto

Uma dica que pode ajudar muito:

Imagine que temos um relacionamento da tabela Mensagem com a Usuario, normalmente fariamos o seguinte para criar um relacionamento:

Mensagem mens = new Mensagem();
mens.Usuario = from us in contexto.UsuarioSet
where us.Id = 10
select us;

contexto.AddToMensagemSet(mens);
contexto.SaveChanges();


O problema é fazemos uma consulta no banco somente para criar o relacionamento, sendo que já temos a informação necessária para isso, o Id do Usuario.
Existe uma outra forma de fazer isso sem consultar o banco de dados:

Mensagem mens = new Mensagem();
mens.UsuarioReference.EntityKey = new EntityKey("YourEntitiesModel.UsuarioSet", "Id", 10);

contexto.AddToMensagemSet(mens);
contexto.SaveChanges();

Assim economizamos um Select, o que faz a diferença quando temos muitas chamadas

ASP.NET MVC no IIS 6.0

02/09/2009 08:25:00 By Felipe Pessoto

Agora com a versão Release Candidate do ASP.NET MVC resolvi começar a estudar sobre o assunto.

Como ainda sou usuário e fã do Windows XP, já imaginei que poderia ter problemas com o IIS 6.0. Acontece que o IIS só passa pro ASP.NET as chamadas que estão configuradas para isso, usando a extensão do arquivo. Então quando você chama a página /Home/About o ASP.NET nem fica sabendo, o IIS logo fala que a página não existe.

Você tem duas opções pra resolver o problema. Uma é adicionar um redirecionamento pro ASP.NET usando o wildcard *, isso faz com que todas as chamadas sejam enviados pro ASP.NET, o que terá impacto no desempenho geral do seu site.

A outra opção, que considero melhor, apesar de alterar sua URL é usar a extensão .aspx nas URLs, /Home/About será /Home.aspx/About. Além de não impactar no desempenho, na maioria das vezes é sua única opção pra quem usa hospedagem compartilhada e não tem acesso ao servidor.

Como o ASP.NET MVC cria os links quando você usa o Html.ActionLink, a única alteração necessária é no Global.asax, onde você vai apagar a rota padrão, e adicionar as seguinte:

routes.MapRoute(
"Default",
"{controller}.aspx/{action}/{id}",
new { action = "Index", id = "" }
);

routes.MapRoute(
"Root",
"",
new { controller = "Home", action = "Index", id = "" }
);

A segunda é apenas para o diretório raiz funcionar.

Depois de mudar o Global.asax basta compilar e atualizar o servidor que já vai funcionar!