O poder do Python

Quem não está acostumado a trabalhar com Django pode estranhar o fato deste utilizar um script Python para fazer a configuração do projeto: o famoso settings.py. E essa estranheza é justificada, afinal muitos desenvolvedores — principalmente os que vêm de outras linguagens — estão acostumados a trabalhar com ferramentas onde tal tarefa é feita com arquivos XML ou coisa assim.

O fato é que utilizar um script Python para tal é uma excelente idéia, pois você deixa de depender de algum tipo de estrutura estática (e muitas vezes inconveniente) para algo mais flexível e poderoso, que, no caso, é a própria linguagem de programação. Isso faz uma grande diferença em situações onde tal flexibilidade é necessária.

Quer exemplos?

Ambientes de desenvolvimento/produção

Eis como fizemos aqui. Primeiramente, defina a variável de ambiente WORKSPACE. No Linux, isso pode ser feito através do arquivo ~/.bashrc:

export WORKSPACE=1

A idéia é possibilitar a criação de perfis de configuração, cada qual correspondente a um ambiente de execução. A existência ou não da variável de ambiente é o que define o ambiente no qual a aplicação roda.

Continuando com o exemplo, no diretório raíz do seu projeto Django, crie o módulo environment.py, com o seguinte conteúdo:

import os
 
def production_mode():
    return not development_mode()
 
def development_mode():
    return 'WORKSPACE' in os.environ

Finalmente, modifique o módulo settings.py para que este utilize tais métodos onde for necessário definir configurações diferentes para ambientes de execução diferentes:

from environment import production_mode
 
# Configurações padrão
PREPEND_WWW = False
DEBUG = True
 
# Configurações para ambiente de produção
if production_mode():
    PREPEND_WWW = True
    DEBUG = False
 
MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.middleware.doc.XViewMiddleware',
    'pages.middleware.PageFallbackMiddleware',
    'django.contrib.redirects.middleware.RedirectFallbackMiddleware',
)
 
# Habilitando caching em modo de produção
if production_mode():
    MIDDLEWARE_CLASSES += (
        'django.middleware.cache.UpdateCacheMiddleware',
        'django.middleware.cache.FetchFromCacheMiddleware',
    )

Não tenha medo de utilizar os recursos do Python onde eles se fizerem necessários, apenas tomando cuidado para não exagerar e acabar criando acidentalmente um Algoritmo Genético para configurar seu projeto!

Informações secretas (IPs, usernames, passwords, etc)

Praticamente não há quem ignore a importância de um bom sistema de controle de revisões (Subversion, Git, etc). O problema é que, muitas vezes, não tomamos o devido cuidado com o que colocamos dentro dos nossos repositórios. Sempre que possível, informações secretas — como endereços de IP, usernames e passwords — devem ser mantidas fora dos repositórios.

Em um projeto Django, as informações de acesso a servidores de e-mail e bancos de dados devem estar disponíveis através do módulo  settings.py. Felizmente, existe um jeito simples de manter essas informações separadas das outras configurações.

Primeiramente, abra o arquivo settings.py do seu projeto e remova todas as senhas e outras informações que você considere secretas. Em seguida, cole o seguinte trecho de código no final do arquivo:

try:
    from private import *
except ImportError:
    pass

Feito isso, crie o módulo private.py no diretório raíz do seu projeto Django. Coloque nele as configurações que você removeu do settings.py no passo anterior. Exemplo:

from environment import production_mode
 
SECRET_KEY = 'secret_key_do_seu_projeto'
 
EMAIL_HOST = 'localhost'
EMAIL_HOST_PASSWORD = 'senha_email_local'
 
DATABASE_HOST = 'localhost'
DATABASE_USER = 'username_db_local'
DATABASE_PASSWORD = 'senha_db_local'
 
if production_mode():
    EMAIL_HOST = 'ip_email_producao'
    EMAIL_HOST_PASSWORD = 'senha_email_producao'
 
    DATABASE_HOST = 'ip_db_producao'
    DATABSE_USER = 'username_db_producao'
    DATABASE_PASSWORD = 'senha_db_producao'

Certifique-se de adicionar o arquivo private.py no ignore (.cvsignore para CVS, .gitignore para Git, etc) correspondente ao sistema de controle de revisões sendo utilizado. Faça o commit e pronto.

Para finalizar, se o seu repositório já contém uma versão “insegura” do módulo settings.py, mude as senhas dos seus servidores.

E você, o que recomenda?

Tem alguma dica útil para compartilhar conosco? Nós adoraríamos ouvir o que você tem a dizer!

Modelo-exemplo de banco de dados

Nem irei perder tempo explicando esse modelo, até porque não há nada nele que precise de explicações. Bem, na verdade, há uma coisa sim: por que raios existe uma tabela só para armazenar os tipos de contato?! Qual é o problema com os bons e velhos códigos fixos (1-email, 2-celular, N-…)?

Um argumento a favor dessa abordagem é que “o usuário pode querer cadastrar um contato cujo tipo não seja suportado pela aplicação”. Mas será mesmo que colocar essa informação no banco de dados resolve o problema? E, mais importante, existe algum efeito colateral?

Bem, na minha experiência, embora essa abordagem pareça boa o bastante para resolver a questão num sistema simples de “cadastro”, a bomba explode quando o sistema passa a depender dessas flags para a realização de lógicas de negócio que vão além do famigerado CRUD.

Anti-pattern?

E se eu te dissesse que usar tabelas no banco de dados para armazenar flags é um anti-pattern? Digo isso pois, como veremos a seguir, as vantagens são irrisórias frente às desvantagens:

Poluição do modelo de dados. Um sistema não muito grande provavelmente conta com mais de uma centena de tabelas. Isso todo mundo sabe. O que todo mundo também sabe, mas parece ignorar, é que não seria surpreendente constatar que 10-15% dessas tabelas serviriam apenas para armazenar flags (situação de pedido, estado civil, forma de pagamento, e por aí vai). E o pior: essas tabelas, quase sempre, possuem exatamente a mesma estrutura, que apelidei carinhosamente de tabelas código-descrição. A tabela TipoContato, mostrada no diagrama que encabeça este texto, é um exemplo desse tipo de tabela.

Ruim para o meio ambiente. Poluir o modelo de dados com dezenas de tabelas código-descrição torna o modelo desnecessariamente maior e mais difícil de compreender. Imprimir um modelo desses consome mais papel, o que é ruim numa época onde o desenvolvimento sustentável está em voga. Quantas árvores suas tabelas código-descrição já derrubaram?

Ultra-normalização. Quanto mais tabelas uma consulta envolver, mais joins, e mais dados indo e vindo para o banco de dados. E, considerando que o banco de dados é (quase) sempre o gargalo, isso não é muito bom para a performance do seu sistema.

Poluição do modelo de objetos. As linguagens com suporte à orientação a objetos figuram entre as mais usadas atualmente, por isso eu diria que muito provavelmente você utiliza esse paradigma no desenvolvimento dos seus sistemas. Se este for o caso, também é bem provável que você utilize algum framework ORM para facilitar a tarefa de integração do software com o banco de dados. Como muitos frameworks ORM exigem um modelo de objetos compatível com o modelo de dados, bem, você acaba sendo forçado a poluir seu modelo de objetos com classes burras que apelidei carinhosamente de (pasmem!) classes código-descrição.

Se tem tabela, tem cadastro. Bom, já que todas as flags possuem suas tabelinhas no banco de dados, isso significa que você, pobre desenvolvedor, terá que fazer “cadastros” para todas elas (e reze para não precisar fazer relatórios, também). Além da chatisse costumeira de se fazer um cadastro, devemos levar em consideração que fazê-los consome tempo e, tempo é dinheiro.

Código quebradiço. Essa é feia. Vamos supor que, nessa nossa aplicação de gerenciamento de clientes/contatos, você queira incluir uma funcionalidade que permita enviar um torpedo ao cliente caso ele possua um contato do tipo Celular. Como mostrado no trecho de código a seguir, você fatalmente terá que incluir no código-fonte referências a registros armazenados no banco de dados, tornando o código quebradiço. Consequentemente, um único UPDATE ou DELETE executado por engano no banco de dados pode fazer o sistema cair de joelhos.

Enviando torpedos a um cliente:

public void enviarTorpedo(Cliente cliente, String texto) {
    // Tenta localizar um contato do tipo celular
    for (Contato contato : cliente.getContatos()) {
         // WTF!! Estamos referenciando um registro do banco de dados!!
         if (contato.getCodigo() == 10L) {
            SMSUtil.enviarTorpedo(contato.getValor(), texto);
            break;
        }
    }
}

A solução

Com certeza existem outros problemas que eu acabei deixando passar, mas espero que os problemas que listei já sejam o suficiente para te convencer que guardar flags em tabelas no banco de dados é uma má idéia.

Mas, como resolver isso então? Simples: use enums sempre que possível. A única desvantagem é que os usuários não poderão mais sair criando novas flags a torto e a direito, o que não é realmente um problema frente às vantagens que as enums oferecem.

Poluição do modelo de dados? As flags virariam campos numéricos ou alfanuméricos nas tabelas que as usam e o framework ORM se encarregaria de converter esses campos de/para objetos enum. Diga adeus às tabelas código-descrição.

Ruim para o meio-ambiente? Sem as tabelas código-descrição, seu modelo fica menor, mais enxuto, facilitando a visualização e gastando menos papel ao imprimí-lo. A natureza agradece.

Ultra-normalização? Usando enums você diminui a quantidade de ligações entre as tabelas, tornando as entidades um pouco mais auto-contidas. Menos tabelas, menos joins, mais performance.

Poluição do modelo de objetos? As enums tomariam o lugar das classes código-descrição, o que por si só tornaria o código mais claro, pois, ao contrário das classes “normais”, as enums possuem um propósito bem definido.

Se tem tabela, tem cadastro? Ué, por que você está com esse sorriso estampado no rosto?

Código quebradiço? Quem mais se beneficia das enums são os trechos de código onde as lógicas de negócio são definidas. Mais especificamente, seu código deixa de referenciar registros do banco de dados, eliminando a fragilidade e melhorando a legibilidade. As enums também impedem que valores arbitrários sejam usados em atribuições e comparações, tornando o código ainda mais confiável. Um exemplo disso pode ser visto no código a seguir, que é uma adaptação da atrocidade do código mostrado anteriormente:

public void enviarTorpedo(Cliente cliente, String texto) {
    for (Contato contato : cliente.getContatos()) {
         // Bem melhor agora!
         if (contato.getTipo() == TipoContato.CELULAR) {
            SMSUtil.enviarTorpedo(contato.getValor(), texto);
            break;
        }
    }
}

O fato de a sua linguagem do coração não ter suporte nativo a enums não deve ser um impedimento para que você deixe de usufruir de suas vantagens. Existem formas de se conseguir uma funcionalidade semelhante sem muito esforço.

Conclusão

Desenvolver software é, antes de tudo, fazer escolhas. É o custo/benefício, os prós e contras antes de se tomar uma decisão. A boa notícia é que o nosso produto, o software, é maleável o suficiente para permitir que decisões ruins sejam re-feitas sempre que elas resultam em problemas como o descrito neste texto.

Bom carnaval!

Hoje, criar e manter uma aplicação com EJBs é relativamente simples. E, por este motivo, a adoção da tecnologia passou a ser mais expressiva, mesmo em projetos menores.

Alguns aspectos da especificação, entretanto, ainda deixam a desejar. Um exemplo seria a parte de injeção de dependências, que é limitada apenas a componentes gerenciados pelo container. O que isso quer dizer? Isso quer dizer que, para você poder tirar proveito do esquema de injeção de dependências, todos os seus componentes precisam ser EJBs.

Mas, nesta versão, os EJBs não são POJOs? Sim, mas ter de expor classes simples como EJBs — só para ganhar essa “injetabilidade” de presente — não parece correto. E, da mesma forma, espalhar instanciações de objetos pelos vários componentes da aplicação definitivamente também não parece.

Por isso, mostrarei a seguir um exemplo de como melhorar a parte de injeção de dependências para que possamos injetar POJOs declarativamente em objetos gerenciados. Como o Spring é (de longe) o framework mais conhecido, eu o usarei para me ajudar nesta tarefa.

O exemplo

Para demonstrar o efeito desejado, veja o trecho de código a seguir:

public interface Calculator {
    int mult(int a, int b);
}
 
public class CalculatorImpl implements Calculator {
    public int mult(int a, int b) {
        return a*b;
    }
}
 
@Remote
public interface MultiplicationRuler {
    int[] rulerFor(int number, int from, int to);
}
 
@Stateless
public class MultiplicationRulerBean implements MultiplicationRuler {
 
    @InjectBean
    private Calculator calculator;
 
    public int[] rulerFor(int number, int from, int to) {
        int total = to-from+1;
        int[] ruler = new int[total];
 
        for (int i = 0; i < total; i++) {
            ruler[i] = calculator.mult(number, from++);
        }
        return ruler;
    }
}

O objetivo aqui é implementar um componente POJO que multiplica dois números. Este componente é usado por um segundo — este sim um EJB — que fornece um método que funciona mais ou menos igual aquelas réguas de tabuada; o método recebe o número desejado e dois outros números que representam os limites da tabuada. Por exemplo, a chamada abaixo retorna os resultados da tabuada de 10, começando no número 1 e indo até o 15:

MultiplicationRulerBean ruler = new MultiplicationRulerBean();
ruler.rulerFor(10,1,15);

Note, na classe MultiplicationRulerBean, que o atributo Calculator está anotado com @InjectBean. Esta anotação servirá para indicar que este campo representa uma dependência que deve ser resolvida injetando-se uma instância de Calculator.

Usando o Spring para obter dependências

Segue um exemplo de arquivo de contexto appcontext-services.xml:

<?xml version="1.0" encoding="UTF-8"?>
<beans>
    <bean id="calculatorBean" class="CalculatorImpl" />
</beans>

Como nossa única dependência externa é uma instância de Calculator, então o arquivo se resume a apenas uma entrada <bean>. Agora, precisamos criar uma classe que será usada para obter os objetos declarados no arquivo mostrado:

public class SpringBeanContext {
 
    private static final SpringBeanContext instance;
    static {
        instance = new SpringBeanContext();
    }
 
    private ApplicationContext context;
 
    private SpringBeanContext() {
        context = new ClassPathXmlApplicationContext("META-INF/spring/appcontext-*.xml");
    }
 
    public Object getBean(Class<?> clazz) {
        Map<?,?> beans = context.getBeansOfType(clazz);
        if (beans != null && beans.size() > 0) {
            return beans.values().iterator().next();
        }
        throw new NoSuchBeanDefinitionException("There's no bean of type " + clazz);
    }
 
    public static SpringBeanContext getInstance() {
        return instance; // retorna o singleton
    }
}

Como apenas precisamos de um objeto da classe SpringBeanContext, esta foi programada como sendo um Singleton. Podemos ver que, quando o Singleton é instanciado, os arquivos de contexto — que seguem a convenção appcontext-[modulo].xml — são carregados pelo Spring. O método getBean() foi criado para que possamos obter objetos gerenciados pelo Spring.

Definindo a anotação @InjectBean

Agora, precisamos criar uma anotação que utilizaremos para indicar as dependências de nossos EJBs:

@Retention(RetentionPolicy.RUNTIME)
public @interface InjectBean {}

A anotação @InjectBean, que não possui parâmetros e é visível em Runtime, servirá para indicar os atributos que representam dependências. O interceptor, que definiremos a seguir, irá procurar por essa anotação nos EJBs interceptados. Então, para cada campo anotado com essa anotação, o interceptor irá obter o objeto correspondente do contexto do Spring e injetá-lo.

O Interceptor

Finalmente chegamos à classe que é responsável por fazer o trabalho pesado:

public class SpringBeanInterceptor {
 
    @PostConstruct
    public void injectSpringBean(InvocationContext context) throws Exception {
        Object target = context.getTarget();
        for (Field field : getAnnotatedFields(target.getClass())) {
            injectBean(target, field);
        }
        context.proceed();
    }
 
    protected List<Field> getAnnotatedFields(Class<?> clazz) {
        List<Field> fields = new LinkedList<Field>();
        for (Field field: clazz.getDeclaredFields()) {
            if (field.getAnnotation(InjectBean.class) != null) {
                fields.add(field);
            }
        }
        return fields;
    }
 
    protected void injectBean(Object target, Field field) throws Exception {
        Object bean = null;
        bean = SpringBeanContext.getInstance().getBean(field.getType());
        if (!field.isAccessible()) {
            field.setAccessible(true);
        }
        field.set(target, bean);
    }
}

Nada de outro mundo, não? Perceba que usamos a anotação @PostConstruct, o que indica que o método anotado deve ser executado para um EJB após sua criação pelo container. Todo método interceptador deve retornar void e esperar um parâmetro do tipo InvocationContext. Neste método, utilizamos um pouco de Reflection para injetar o objeto fornecido pelo Spring. Por fim, para que outros possíveis interceptors (e o próprio método sendo interceptado) possam ser invocados, chamamos InvocationContext.proceed().

Para finalizar o exemplo, nos resta associar este interceptor com o EJB da aplicação. Uma forma simples de fazer isso seria através do uso da anotação @Interceptors nas classes e métodos desejados. Por exemplo:

@Stateless
@Interceptors(SpringBeanInterceptor.class)
public class MultiplicationRulerBean implements MultiplicationRuler {
 
    @InjectBean
    private Calculator calculator;
 
    // ...
}

Claro que, para este pequeno exemplo, esta abordagem poderia ser utilizada sem nenhum problema. Porém, definir o interceptor dessa forma é muito trabalhoso em situações onde temos muitos EJBs.

Para que possamos evitar o uso repetido da anotação @Interceptors, podemos fazer a configuração via XML, o que nos permite associar um interceptor a vários EJBs através do uso de curingas. Para isso, basta modificar o arquivo ejb-jar.xml:

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar>
    <interceptors>
        <interceptor>
            <description>Spring-aware interceptor</description>
            <interceptor-class>com.destaquenet.tutorial.interceptor.SpringBeanInterceptor</interceptor-class>
        </interceptor>
    </interceptors>
 
    <assembly-descriptor>
        <interceptor-binding>
            <ejb-name>*</ejb-name>
            <interceptor-class>com.destaquenet.tutorial.interceptor.SpringBeanInterceptor</interceptor-class>
        </interceptor-binding>
    </assembly-descriptor>
</ejb-jar>

Neste caso, estamos associando o interceptor automaticamente a todos os EJBs, nos livrando de ter que configurar manualmente a associação do interceptor com possíveis novos EJBs que a aplicação venha a ter.

Conclusão

Venho observando que frameworks como o Spring e a especificação JavaEE estão trilhando caminhos diretamente opostos; enquando os primeiros estão crescendo descontroladamente e ficando cada vez mais complexos, o segundo está tirando a gordura e ficando mais simples de usar. Claro que cada desenvolvedor tem seus motivos para escolher um ou outro, mas eu particularmente já não vejo tanta vantagem em se adotar o Spring ao EJB. Por outro lado, penso ser mais interessante a junção dessas tecnologias de modo que cada uma contribua com o seu melhor.

Como vimos, a especificação JavaEE 5 — que foi projetada para ser estensível e fácil de usar — conta com componentes denominados interceptors, que nos fornecem um recurso à la AOP, nos permitindo executar código em pontos bem definidos durante a execução da aplicação.

Eu nem preciso dizer que os interceptors podem ser usados para outras coisas além da mostrada aqui. Apenas para citar um exemplo, o framework Seam usa interceptors para implementar o que seus autores chamam de Bijeção — que permite que um componente qualquer possa receber/ejetar dependências de/para um contexto.

Os conceitos apresentados aqui podem ser adaptados para uso com outros frameworks de injeção de dependências, como Guice e PicoContainer.