Um alô pra galera de TI! Em breve vou publicar uma série de posts explicando o modelo de arquitetura adotado para um projeto que estou atuando...

Com um cliente (diga-se em potencial, risos), chegamos a alguns requisitos que a aplicação deveria obedecer, como desacoplamento entre os módulos do sistema, seguir algum design pattern consagrado (como MVVM) e a agilidade de uma camada de persistência (pois na altura do campeonato, fazer tudo na mão, via loops-oops, não rola mais em sistemas de informação modernos).

Uma vez que você entende como essas partes se interagem num sistema, dificilmente você vai querer seguir outra linha (de pensamento). Foi assim comigo, pelo menos!

E antes de começar, respondo algumas possíveis dúvidas:

Por que usar NHIBERNATE, sendo que há o Entity Framework v4.0 da gigante Microsoft? Essa camada de persistência segue o padrão POCO (plain old class objects) desde o início e vai contribuir para o modelo desacoplado da solução. O Entity Framework talvez utilize um modelo de mapeamento mais inteligente (obviamente mais complexo), mas é muito acoplado com as classes dum sistema, minha opinião.

Tenha em mente: se a modelagem das tabelas for complexa, as operações envolvendo seus dados serão complexas também. Ou seja, uma camada de persistência não aumenta a complexidade da aplicação (exclui-se o tempo de aprendizagem aqui).

Por que usar FLUENT? Justamente por causa do NHIBERNATE e seus conhecidos hbms para mapeamento objeto-relacional. Utilizando FLUENT, economiza-se muito tempo no mapeamento das entidades e, quando a modelagem não está de acordo com as tabelas da base de dados, o FLUENT vai nos ajudar a detectar problemas (muito difícil de ser feito no modo tradicional com os hbms, a não ser por esperar erros em runtime). Quem já trabalhou com esses hbms sabe o pé no saco.

E finalmente: por que usar PRISM? O PRISM está preparado para MVVM e o modelo desacoplado que preciso para o meu projeto. Com ele, eu posso configurar um módulo de recursos visuais (e relacionar as dependências com outros módulos da aplicação) totalmente separado... caso seja necessário trocar de estilo visual, desenvolve-se uma outra biblioteca de recursos. É só configurar para que a aplicação assuma esse novo módulo. Vou seguir com um tipo de container chamado MEF do PRISM (adotado no projeto).

Esse tipo de container MEF nos oferece a opção de abstrair completamente uma interface (a definição mais básica) da classe concreta que a implementa e fornece de fato a funcionalidade! Um exemplo mais claro, tenho a interface IAnimal feita em c#:

public interface IAnimal {
   string EmitirSom();
}

E classes que implementarão essa interface (código de exemplo):

[Export("Cachorro", typeof(IAnimal))]
public class Cachorro: IAnimal {
   public string EmitirSom() { return "Au Au (Hehehe)!"; }
}

[Export("Gato", typeof(IAnimal))]
public class Gato: IAnimal {
   public string EmitirSom() { return "miaaaaau (queimando no churrasco)"; }
}

Com essa opção de container, essas duas classes nem precisam estar no mesmo Assembly que o PRISM dará conta de descobri-las em runtime (por meio do export com a interface IAnimal). E essa capacidade será reaproveitada para a classe que utilizará os recursos do nhibernate + fluent na persistência ao banco de dados.

Só um exemplo! Existem mais coisas envolvidas para que o PRISM funcione corretamente.

Enfim, vou arranjar tempo para explicar um pouco cada uma das partes, ou indicar materiais técnicos quando precisar aproximar a explicação mais para o meu projeto em particular. Bom, nos vemos lá!