A Microsoft jura que não mas ao que tudo indica, para aplicações WEB será adotado o padrão MVC, através do ASP.NET MVC, ficando os Web Forms em segundo plano.

Apesar de ser uma grande quebra de paradigma em relação aos “antigos” Web Forms, a introdução deste padrão traz consigo uma série de vantagens, entre as quais eu destaco a maior facilidade de deixar o site dentro dos webstandards, a testabilidade e uma série de recursos que deixam o trabalho mais produtivo.

Dificilmente alguém irá converter todo um projeto web já pronto em Web Forms de uma só vez para MVC, afinal isso exigiria tempo e dinheiro que ninguém tem.
Felizmente, é possível conviver com os dois tipos de padrões ao mesmo tempo, possibilitando uma conversão gradual e/ou usar o que cada  padrão tem de melhor.

Por outro lado você pode preferir (como eu), usar o tipo de projeto “Website” ao invés do tipo Web Application que vem por default no ASP.Net MVC. As dicas abaixo servirão para esse caso também.

Instalando o Kit-Gás no seu Web Site.

É extremamente simples deixar seu site preparado para trabalhar de forma híbrida:

Leia mais...

Em aplicações asp.net (webforms), uma das dúvidas freqüentes é o que fazer após uma ação, como por exemplo, gravar um novo registro. Acredito que seja comum a simples exibição de uma mensagem “Registro salvo com sucesso”, na mesma página onde os registros foram salvos.
Alguns problemas podem ocorrer com essa prática: caso o usuário submeta o formulário novamente, o registro poderá ser duplicado. Se pressionar atualizar, será exibida uma mensagem como a abaixo (a mensagem pode variar de acordo com o browser):

Para evitar esse tipo de problema deve-se procurar utilizar o Design Pattern PRG, onde após um post (submit), respondemos com um redirect para uma nova página, ao invés de simplesmente retornar um HTML, ou seja, no caso do asp.net, utilizamos o comando Response.Redirect(“pagina_sucesso.aspx”) para direcionar à uma nova página onde informaremos que o registro foi salvo com sucesso.

Faz tempo que não falo da Google. Aliás, faz certo tempo que não falo de nada aqui, e vou quebrar o jejum com uma notícia muito interessante: os serviços Google para clientes da versão “premier edition” agora contam com SLA (Service Level Agreement) de 99.9% para os serviços. Google Calendar, Google Docs, Google Sites, and Google Talk. Esse SLA já estava disponível para o Gmail

Isso é uma boa notícia, principalmente para as corporações que precisam de serviços básicos como agenda, planilha e documentos em cloud e/ou não querem investir em infra interna.

Segundo o Blog do Google, no último ano o Gmail conseguiu 99.9% de disponibilidade. Pense no seu provedor de email (seja ele o Terra, UOL, algum fundo de quintal qualquer ou o mesmo provedor que hospeda suas páginas). Será que você conseguiu tanto tempo de disponibilidade assim em um desses fornecedores?
Quantas vezes você já ficou sem acessar seu email? Quantas vezes você já perdeu seus emails ao trocar de provedor, formatar sua máquina, etc, etc.

Uso o Gmail desde 26/07/2004 (data da primeira mensagem que tenho arquivada). Tenho milhares de mensagens arquivadas (só apago as realmente inúteis). Acesso meu email de qualquer lugar a qualquer hora, com qualquer dispositivo. Nunca passei raiva, nunca precisei xingar.

Recentemente passei a manter todos os meus docs on-line no Google Docs. Além disso, mantenho uma base de conhecimentos em fotografia (meu assunto offline preferido!) usando o Google Sites (que é uma espécie de wiki no final das contas).

Apesar de meu ganha-pão ser no mundo Microsoft, sou obrigado a reconhecer que nesses serviços (e em outros como o Google Maps) a Google está muito na frente da Microsoft. O Hotmail (ou Windows Live Mail, como preferirem) é inusável se comparado com o Gmail (é lento, cheio de propaganda, etc). E, sinceramente, ainda não confio o suficiente nesses serviços da Microsoft ( lá se foi qualquer chance que eu tinha de ganhar algum título MVP! ).

Quem trabalha no desenvolvimento de aplicações asp.net deve ter se deparado várias vezes com a necessidade de depurar código diretamente no servidor de produção (ou de testes). Situações como implementação de operações de cartões de crédito em B2C são difíceis de se reproduzir na máquina de desenvolvimento pois envolvem callback externo.

Se você tem acesso ao seu servidor, pode utilizar o recurso de debug remoto do Visual Studio. É algo relativamente trivial de ser feito, mas pouco comentado.

Leia mais...

Continuando a série Design Patterns, nessa parte 2 iremos ver o padrão Observer.

Suponha que você tenha uma linha de produção que é automaticamente alimentada de componentes por diversos robôs assim que entra um novo pedido. Cada robô solta um determinado número de peças por quantidade de pedido.

Uma primeira abordagem seria algo como abaixo:

using System;

namespace NadaObserver
{
    class Program
    {
        static void Main(string[] args)
        {
            LinhaProducao linha1 = new LinhaProducao();
            Robo wallE = new Robo("Wall-E",linha1, 1);
            Robo c3po = new Robo("C3PO", linha1, 10);
            Robo sonny = new Robo("Sonny", linha1, 20);
            Robo terminator = new Robo("Terminator 800", linha1, 1000);

            //entrou novo pedido de 10 peças
            Pedido ped = new Pedido(10);
            
            // põe o povo para trabalhar

            wallE.SuprirPecas(ped.QtPedido);
            c3po.SuprirPecas(ped.QtPedido);
            sonny.SuprirPecas(ped.QtPedido);

            Console.ReadLine();
            
        }
    }

    public class Pedido{

        public Pedido(int qtPedido)
        {
            this.QtPedido = qtPedido;
        }

        public int QtPedido { get; set; }
       
    }


    public class LinhaProducao{

        public LinhaProducao()
        {
        }

        public void ReceberPecasDoRobo(int qtPecas)
        {
            Console.WriteLine("Recebi {0} peças para montagem", qtPecas);
        }
    }

    public class Robo
    {
        private int _fatorPecasPorPedido = 1;
        
        private LinhaProducao _linhaDeProducao = null;

        public Robo(string nomeRobo, LinhaProducao linhaDeProducao, int fatorPecasPorPedido)
        {
            this.NomeRobo = nomeRobo;
            this._linhaDeProducao = linhaDeProducao;
            this._fatorPecasPorPedido = fatorPecasPorPedido;
        }

        public string NomeRobo { get; set; }

        public void SuprirPecas(int qtItensPedido)
        {
            this._linhaDeProducao.ReceberPecasDoRobo(qtItensPedido * this._fatorPecasPorPedido);
        }
 
    }
}

Além de deselegante, essa solução trás alguns problemas: a aplicação chamadora sempre deverá saber quais são os robôs que estão ligados à cada linha de produção.

Leia mais...

Talvez uma das coisas que mais perturbam os usuários da web seja a necessidade de decorar vários logins e senhas para os diversos sites onde eles possuam uma conta.

Para solucionar isso existem várias iniciativas de se criar “passaportes universais”, como por exemplo, o OpenId.

A Microsoft disponibiliza também uma solução para isso, o Windows Live ID Web Authentication com o qual os usuários podem se logar nos sites usando a mesma conta do Hotmail/MSN. Para os desenvolvedores é uma solução interessante pois traz agilidade na autenticação para milhões de pessoas que já possuem uma conta no MSN.

O WLIWA (abreviando) é um serviço altamente escalável pois fornece, segundo a Microsoft, mais de 22 bilhões de autenticações/mês (cada vez que uma pessoa entra no MSN ela está se autenticando pelo WLIWA). A segurança dele é auditada constantemente o que nos dá uma segurança a mais. Considerando as preocupações que temos com segurança, deixar a autenticação com um especialista já nos poupa muito trabalho.

Veja no diagrama abaixo  como funciona  o processo de autenticação:

Perceba pelos ítens 3 a 7 que o usuário passa seus dados de autenticação DIRETO para o Windows Live Id. Seu site não toma conhecimento dos dados de login do usuário (o que é uma segurança para o seu usuário).
Assim que a autenticação for concluída com sucesso, o WLIWA retorna para o seu site um token com o identificador único do usuário. Esse token você irá usar para autenticar o usuário em sua aplicação.

Li hoje esse post e achei interessante compartilhar. Jason Young sugere algumas questões que você deveria fazer durante uma entrevista de emprego para seu possível empregador.

Longe de ser petulância, essas perguntas evitam futuros dissabores para ambas as partes. Já fui empregador também e sei que nada disso é absurdo ou ofende o entrevistado.

Vou traduzir algumas de forma “livre”, até porque algumas necessitam de “regionalização”:

1) Que tipo de controle de versão vocês usam?

No Brasil, infelizmente, primeiro temos que perguntar se a empresa faz controle de versão, já que não é uma cultura muito difundida principalmente nas empresas mais antigas.

Se a empresa ainda usa Source Safe, fique preocupado! Empresas mais atualizadas procuram utilizar controles mais modernos como o Subversion ou o Team Foundation Server.

Leia mais...

No post “Linq to SQL Context único por aplicação” demonstrei a utilização de um Singleton para disponibilizar um único Linq Context por aplicação.

Para muitos é óbvio o que é um Singleton bem como um Design Pattern. No entanto, pensando em quem não conhece muito bem esses conceitos resolvi criar uma série de posts para demonstrar alguns dos principais design patterns que podemos usar no dia a dia.

Primeiramente, o que é um Design Pattern? Segundo a Wikipédia, “Design Patterns, descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos”.
Ou seja, são peças de código, estratégias de resolução, etc, que nos poupam tempo na resolução de problemas pelos quais outros desenvolvedores já passaram. Essas soluções são amplamente utilizadas e testadas, não havendo, geralmente, contestações sobre o seu funcionamento.

Acredito que o maior problema com relação aos DP (Design Patterns) seja “quando” utilizá-los. Percebo que há muita confusão com relação a isso, devido principalmente quando se tenta utilizá-los a qualquer custo, apenas para estar “na moda”.

A primeira coisa que você precisa saber sobre os Design Patterns é: design patterns se encaixam na categoria best practices, ou seja, seria bom se você utilizasse, mas você não será condenado à forca caso não utilize.

Em seguida, você deve saber que deve procurar um design pattern para um problema, não o contrário, ou seja, achar algum problema para tentar enquadrá-lo sob um Design Pattern. Essa última situação é a mais comum quando se tenta apenas seguir a moda.

Sugiro que você procure ter uma visão geral sobre os principais Design Patterns para que no momento em que precisar de algum deles você tenha a percepção “automática” de que ele pode ser auxiliado por algo que outro desenvolvedor já pensou.

Design Patterns normalmente são independentes de linguagem, mas a implementação deles pode variar de acordo com os recursos disponíveis em cada linguagem. Obviamente aqui irei focar em C#.

Primeiro Pattern: Singleton

Leia mais...

Otávio P. Coelho escreveu recentemente um post sugerindo o uso de singletons para manter o contexto de um Entity Data Model.

Venho utilizando essa estratégia há um bom tempo já  para minhas aplicações que usam Linq to SQL e a partir do post do Otávio resolvi compartilhar um trecho de código que pode ser usado por todos.

Qual a vantagem de criar um singleton para isso? Bom, imagine que uma determinada rotina do seu código precise “atravessar”  por vários métodos de instâncias de várias classes e imagine que essa “travessia” precise estar coberta por uma transação. Você não pode então criar uma instância do seu data context em cada método e passar um context já criado e passar como parâmetro é uma solução muito “feia” além  de não permitir a separação das suas regras de negócio da camada de persistência.

Com um singleton, os métodos passam a “buscar” um data context já aberto, ou, se ainda não estiver criado, instancia um novo.

Usando os métodos CallContext e SetContext podemos manter o data context no contexto da aplicação, o que significa que em aplicações Windows Forms ele estará válido durante toda a execução do programa, ou no caso de aplicações WEB, durante o ciclo de vida de uma chamada Http Request.

Essa solução é transparente para aplicações WEB e Desktop, ou seja, se sua camada de negócios e/ou sua camada de persistência são usadas simultaneamente nas duas plataformas, a solução não precisa ser “ajustada”.

Exemplo abaixo, DataRepository é o nome do meu Data Context. Substitua pelo seu.

using System.Runtime.Remoting.Messaging;

namespace LINQToSQL
{
    public class Helper
    {
        #region Privates

        private static string _stringConexao = null;

        private const string DATACONTEXT_ITEMS_KEY = "DBHelperContextKey";

        private static DataRepository DataBaseContext
        {
            get
            {
                return (DataRepository)CallContext.GetData(DATACONTEXT_ITEMS_KEY);
            }
            set
            {
                CallContext.SetData(DATACONTEXT_ITEMS_KEY, value);
            }
        }

        #endregion

        #region Public and Protected Properties and Methods

        /* a string de conexão você pode manter de várias formas
         * talvez a mais prática seja recuperar diretamente via ConfigurationManager
         */
        public static string StringConexao
        {
            get
            {
                return _stringConexao;
            }
            set
            {
                if (_stringConexao != null && _stringConexao.Equals(value))
                    return;

                //Se já tem um DatabaseContext criado, elimina ele para
                //que na próxima chamada seja reaberto com a nova string
                //de conexao.
                if (DataBaseContext != null)
                {
                    CleanUp();
                }

                _stringConexao = value;
            }
        }

        public static DataRepository Db
        {
            get
            {
                if (DataBaseContext == null)
                {
                    DataBaseContext = new DataRepository(StringConexao);
                }

                return DataBaseContext;
            }
        }

        public static System.IO.TextWriter Log
        {
            get
            {
                return Db.Log;
            }
            set
            {
                Db.Log = value;
            }
        }

        public static void CleanUp()
        {
            if (DataBaseContext != null)
            {
                DataBaseContext.Dispose();
                DataBaseContext = null;
            }
        }

        #endregion
    }
}

Na empresa em que trabalho, fiquei responsável pela criação de um servidor SVN usando o Active Directory para autenticação dos usuários juntamente com um gerador de builds automatizados.

Irei relatar como montei esse servidor. Se esse post está no ar é porque deu tudo certo!

As ferramentas que utilizadas são:

a) Servidor (que chamarei de SVNSERVER) usando o Windows XP como sistema operacional. O ideal seria uma versão server obviamente, mas não queríamos torrar uma licença de servidor apenas para isso. No entanto, os fontes não ficarão nessa máquina, serão gravadas em um servidor de arquivos com backup automatizado.

b) Subversion para controle de versão. Como usaremos o Apache de intermediário para autenticação no AD, temos que utilizar o build correto, de acordo com a versão do Apache que estivermos utilizando. Usarei a versão gerada com o Apache 2.2. Cuidado com as versões: no momento em que eu escrevo este artigo, a versão do setup é a do SVN 1.4, no entanto, o Tortoise (item d) está usando o SVN 1.5. Eu instalei o SVN via setup e depois atualizei manualmente através do arquivo zipado que está na mesma pasta ( http://subversion.tigris.org/files/documents/15/43244/svn-win32-1.5.1.zip)

c) Apache HTTPD: o servidor apache será responsável pela interface entre o SVN e o Active Directory. A versão que irei utilizar é a http://linorg.usp.br/apache/httpd/binaries/win32/apache_2.2.9-win32-x86-openssl-0.9.8h-r2.msi

d) Tortoise SVN: cliente gráfico para o SVN.

Instalação

Instalei os programas na seguinte ordem:

Leia mais...