Configurando o Castle ActiveRecord em aplicações web

Configurar o Castle ActiveRecord em aplicações web é uma tarefa fácil. Porém, as documentações oficiais sobre isso são um pouco confusas. Neste post pretendo mostrar da forma mais simples possível como fazer uma configuração básica do Castle ActiveRecord.

Primeiro Passo - Instale os assemblies no computador de desenvolvimento

O site oficial do Castle ActiveRecord disponibiliza um instalador que registra os assemblies em seu computador de desenvolvimento, isso facilita na hora de referenciar no seu projeto, os assemblies aparecerão entre as referências do .Net na janela Add Reference do Visual Studio.
Se você preferir, pode apenas baixar e copiar os Assemblies para seu computador.
Página de download do site oficial

Segundo Passo - Adicione as referências ao seu projeto

Adicione as seguintes referências, elas vêm no pacote baixado do site oficial.

• Castle.ActiveRecord.dll
• NHibernate.dll

Se você usou o instalador para instalar os assemblies, eles estarão na aba .Net da janela Add Reference do Visual Studio. Caso contrário, procure-os manualmente.

Terceiro Passo - Configure o web.config

Para SQL server, o web.config deverá ficar assim:

Para o Oracle, deverá ficar assim:

Quarto Passo - Inicialização do Framework no global.asax

Por fim, é necessário codificar a inicialização do Castle ActiveRecord, que deverá acontecer somente na inicialização da aplicação web. Para isso, devemos chamar o método Initialize da classe ActiveRecordStarter, passando as configurações que guardamos no web.config e todos os tipos que criamos que extendem a classe ActiveRecordBase. Ex:

    Sub Session_Start(ByVal sender As Object, ByVal e As EventArgs)
        ' Fires when the session is started
        Dim _Config As Castle.ActiveRecord.Framework.IConfigurationSource
        _Config = System.Configuration.ConfigurationManager.GetSection("activerecord")
        Castle.ActiveRecord.ActiveRecordStarter.Initialize(_Config, _
        GetType(Blog), _
        GetType(Post) _
        )
    End Sub

Caso você não possa modificar o código do global.asax (se você está usando DotNetNuke, por exemplo), você pode fazer a inicialização em um HttpModule. Porém, como a inicialização de um HttpModule não acontece sempre quando a aplicação web inicializa (as vezes um HttpModule é inicializado mais de uma vez), você deverá usar um work-around: crie uma classe com o código da inicialização em seu contrutor estático e, no evento Init do HttpModule, apenas chame um método qualquer da classe onde está a inicialização (não precisa ter nenhum código neste método). Em breve postarei sobre esta técnica com mais detalhes.

Princípios de Design Orientado a Objetos

A etapa de arquitetura de software é crucial para o futuro de qualquer projeto de sistema. Ela é feita logo antes da fase de construção do projeto e se bem planejada, ajudará bastante o projeto ser bem sucedido. Porém, uma arquitetura mal planejada é garantia de um projeto com problemas em diversas fases, desde a construção até a manutenção.
Em grandes projetos existe uma separação clara de papéis que define quem deverá ser responsável pela tarefa de definir a arquitetura do software, que geralmente é feita por uma pessoa especializada nisso, o Arquiteto de Software. Porém, em projetos ou empresas menores, observamos que essa tarefa geralmente é realizada por outras pessoas, como o Analista de Sistemas ou o próprio Desenvolvedor. Desta forma, estudar arquitetura de software é essencial não só aos que são (ou pretendem ser) arquitetos de software.
Neste post pretendo apresentar uma introdução à arquitetura de software orientada a objetos, essencial para quem deseja (ou precisa) arquitetar um software.

Quando decidimos desenvolver um software utilizando o paradigma da orientação a objetos, o fazemos com dois objetivos principais em mente, que são:

Diminuir o acoplamento

Ou seja, deixar as partes do sistema fáceis de de ser trocadas ou utilizadas por outras partes.

Aumentar a coesão

Ou seja, fazer com que as partes do sistema tenham excelência em fazer aquilo que se propõem sem depender de outras partes.

Robert Martin, em seu livro Agile Software Development: Principles, Patterns, and Practices, nos mostra alguns princípios que se bem observados na arquitetura do software orientado a objetos, trazem agilidade no desenvolvimento, estabilização, implantação e manutenção dos projetos.

Estes princípios nos ajudam a atingir os nossos dois objetivos tentando remover do software as seguintes características:

Rigidêz

Que é a dificuldade de fazer uma alteração numa parte do software porque ela afetaria muitas outras partes.

Fragilidade

Que é o surgimento de erros em diversas partes do software quando você altera alguma parte.

Imobilidade

Que é a impossibilidade de reutilizar partes do software porque não é possível "desencaixá-las" de todo o resto.

Sabendo isso, vamos aos princípios:

Princípio Aberto-Fechado

Classes, módulos e funções devem ser abertas para extensão, mas fechadas para modificações.
Ou seja: ao criar um sub-classe, por exemplo, você não deverá alterar nada no comportamento da classe base, ela deve permanecer intacta.Utilizar classes abstratas ou interfaces ajudam a reforçar este princípio.

Princípio da Inversão de Dependência

Partes de mais alto nível não devem depender das partes de menor nível. Ambas devem depender de abstrações; e
Abstrações não devem depender de detalhes. Os detalhes é que devem depender de abstrações;
Ou seja: Entre as classes de alto nível e as classes de baixo nível, devemos introduzir classes abstratas.
Isso permite que troquemos facilmente as classes de baixo nível sem afetar as de alto nível.
Para fazer isso, a parte abstrata deve ser definida e depois não mais alteradas (Aberto-Fechado), isso significa que devemos fazer as classes específicas (detalhes) seguindo as abstrações e caso a abstração não sirva, devemos extendê-la: nunca alterá-la.

Princípio da Segregação de Interfaces

Clientes não devem ser forçados a depender de iterfaces que eles não usam
Ou seja: devemos tomar cuidado ao criar interfaces para não colocarmos métodos nela que não são realmente necessários para qualquer classe que implemente essa interface.
Interfaces com métodos desse tipo são chamadas de interfaces poluídas. Devemos evitá-las.

Princípio da Responsabilidade Única

Uma classe deve ter uma única razão para mudar
Ou seja: uma classe deve ter uma única razão para mudar. Se identificarmos que ela está com mais de uma razão para mudar, devemos separá-la em duas classes.

Princípio da Substituição de Liskov

Sub-tipos devem ser completamente substituíveis por seu tipo-base
Ou seja: isso reforça o princípio Aberto-Fechado. Se você utilizar um objeto e através do polimorfismo manipulá-lo como sendo do seu tipo base, ele deve funcionar corretamente e deve se comportar da mesma forma como se comportaria se ele realmente fosse daquele tipo.

Os Design Patterns, tão falados atualmente, são "receitas" de como resolver determinados problemas corriqueiros seguindo os princípios aqui apresentados.
Seguindo estes princípios, com certeza ganhamos agilidade no desenvolvimento de software, além de aumentarmos, e muito, a qualidade dele. Uma coisa importante que não podemos deixar de ter em mente é que princípios não são regras, nós devemos sempre saber quando abrir mão de um princípio para não deixarmos o software desnecessariamente complexo.

Espero que isto possa ajudar a quem está se deparando com a tarefa de definir a arquitetura de um software e não sabe por onde começar. Abrasssss!