Com o Fluent Nhibernate e possivel utilizar-se do padrao Convention over Configuration, Convencao sobre Configuracao, quem e programador Java, ou de outras linguagens de script ja usam bastante deste padrao, mas para .Net isto nao e tao comum assim. Este padrao permite que nao precisamos configurar nosso mapeamento, pois ele esta implicito na declaracao de nossas classes, possibilitado pela convencao. Por exemplo quando criamos um campo Id em nossa classe nao necessitamos mapear essa propriedade, pois a convencao nos diz q ele vai ser uma chave primaria de nossa tabela.O Fluent Nhibernate permite que seja mapeado as classe atraves dessa convencao, devemos apenas dizer quais as nossas classes devem ser mapeadas.var mapeamento = AutoMap.AssemblyOf<Dominio.Entidades.Core.Usuario>(convencoes); //Qual assembly deve ser mapeadovar cfgFluent = FluentNHibernate.Cfg.Fluently.Configure(cfg).Mappings(x =>x.AutoMappings.Add(mapeamento));cfg = cfgFluent.BuildConfiguration();this.FabricaSessao = BuildSessionFactory(cfg);No caso acima passamos o assembly da classe Usuario, fazendo com que todas as outras classes sejam mapeadas.public class Usuario : IEntidade{public virtual long Id { get; set; }public virtual string Nome { get; set; }}A classe Usuario sera mapeada para um tabela, onde o Id sera a chave primaria, e o campo Nome sera um varchar.Porem necessitamos fazer alguns refinamentos nesses mapeamentos, por exemplo caso queiramos adicionar um prefixo no nome da tabela, ou por exemplo definir o tamanho do campo Nome no banco? Teremos que adicionar os mapeamentos um a um? Ai entra a possibilidade de extensao do Fluent, todas as convencoes podem ser implementadas manualmente extendendo as convencoes padroes.public class TableNameConvention : IClassConvention{public void Apply(IClassInstance instance){instance.Table("tb_" + instance.EntityType.Name);}}Neste exemplo criamos uma convencao para o nome da tabela que sera gerado, implementamos o IClassConvention, e setamos o nome da tabela que queremos. Todas as interfaces que podem ser implementadas estao no namespace using FluentNHibernate.Conventions. Na hora de configurar o Fluent devemos adicionar nossas convencoes antes de criar a SessionFactory.var mapeamento = AutoMap.AssemblyOf<Dominio.Entidades.Core.Usuario>(convencoes); //Qual assembly deve ser mapeadomapeamento.Conventions.Add<TableNameConvention>();mapeamento.Conventions.Add<PrimaryKeyNameConvention>();var cfgFluent = FluentNHibernate.Cfg.Fluently.Configure(cfg).Mappings(x =>x.AutoMappings.Add(mapeamento));Desta forma o Fluent sabera que devera usar nossas classes de configuracao. Essa apenas uma das maneiras que o Fluent permite fazer, temos outras mais em exemplos por ai na internet. Vale a pena dar uma olhada e verificar qual melhor se aplica ao seu projeto. Isso e muito util no caso de voce ja ter algumas convencoes que usa e nao quer mudar e para codigo legado. Para quem nao conhece o Team City, e um servidor para integracao continua, ou seja, ele verifica os commits de seu sistema de versao, baixa a versao, compila, e depois envia para o seu servidor, e pode fazer muito mais, isto tudo de maneira automatizada sem interferencia humana. http://www.jetbrains.com/teamcity/ Voce pode baixar ele gratuitamente do site. Ele tem suporte ate 20 configuracoes de build no modo gratuito. Para voce ter uma nocao, se voce tiver apenas alguns projetos em sua solucao e nao muitos locais para publicar essa versao serve. No meu caso, eu tenho dois projetos Windows para publicar via clickonce, um website, e um servico WCF. Todas as quatro publicacoes sao publicadas para dois servidores diferentes via ftp, e para tudo isso necessitei de apenas 4 configuracoes de build. No proximo post vou ensinar