NHibernate para iniciantes

12/07/2012

Esse é o primeiro post de uma possível série sobre o NHibernate.

NHibernate para quem não sabe é uma poderosa ferramenta para ORM. Portado para o .net a partir do Hibernate Core originalmente escrito em Java como diz o site oficial do projeto.

Para iniciar vou criar um pequeno projeto de exemplo, onde terei uma entidade representando meus clientes como visto abaixo:

E a classe Cliente:

namespace Dominio
{
public class Cliente
{
public virtual int ID { get; set; }
public virtual string Nome { get; set; }
public virtual long CPF { get; set; }
public virtual string Email { get; set; }
}
}

Notem que todas as propriedades tem o modificador virtual, isso é por conta do lazy-load ser o modelo default do NHibernate, mas voltaremos nesse ponto mais tarde.
Também precisaremos de uma tabela em um banco de dados para a persistência dos dados:

Agora vamos ao NHibernate, o primeiro passo é adicionar as referencias que ele utiliza. Para isso utilizarei o Nuget no VS2010:

Observação: Instalei apenas o NHibernate, o Iesi.Collections é instalado automaticamente.
Agora vamos ao mapeamento da entidade… Mas o que é um mapeamento?
Simples, é o que usamos para dizer ao sistema em que tabela está sua entidade e quais campos representam cada propriedade. (Pelo menos de forma superficial é isso!)
Por padrão NHibernate utiliza arquivos xml para descrever esse mapeamento. Veremos outras formas mais adiante…

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" assembly="Dominio" namespace="Dominio">
<class name="Cliente">
<id name="ID">
<generator class="sequence"/>
</id>
<property name="Nome"/>
<property name="CPF"/>
<property name="Email"/>
</class>
</hibernate-mapping>

Notem que em momento nenhum definimos nomes de tabela ou de campos, então o NHibernate assume que os nomes são idênticos. Caso queira nomes distintos existem os atributos table e column nas tags class e property/id respectivamente.
Outra informação interessante é a tag generator que define o tipo do incremento na tabela.

UPDATE: Esse arquivo deve ter a propriedade Build Action marcado como Embedded-Resource na aba propriedades

E agora precisamos configurar o NHibernate para acessar o banco de dados.
Como? Com outro arquivo xml!

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
<session-factory>
<property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
<property name="dialect">NHibernate.Dialect.MsSql2008Dialect</property>
<property name="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
<property name="connection.connection_string">Data Source=.\SQLEXPRESS;Initial Catalog=FunilariaKaiser;Integrated Security=True</property>
<property name="show_sql">true</property>
</session-factory>
</hibernate-configuration>

Esse xml define qual o banco de dados e o tipo de conexão. Existe uma ampla gama de providers disponíveis.

UPDATE: Esse arquivo deve ter a propriedade Copy to Output Directory marcado como Copy always na aba propriedades

Por fim o nosso domínio está preparado para NHibernate. Mas como manipulamos os dados? Bem para isso vou utilizar um repositorio descrito por Eric Evans no livro DDD.
Para isso criei uma nova classe chamada RepositorioClientes:

using NHibernate;
using NHibernate.Cfg;

namespace Dominio
{
public class RepositorioClientes
{
private ISessionFactory _sessionFactory;

public RepositorioClientes()
{
var configuration = new Configuration();
configuration.Configure();
configuration.AddAssembly(typeof(Cliente).Assembly);
_sessionFactory = configuration.BuildSessionFactory();
}

public void Salvar(Cliente cliente)
{
using (ISession session = _sessionFactory.OpenSession())
{
using (ITransaction transaction = session.BeginTransaction())
{
session.Save(cliente);
transaction.Commit();
}
}
}
}
}

Notem que no construtor dessa classe crio uma instancia de Configuration, esse é o responsável por interpretar os xml’s que criamos anteriormente.
No método Salvar, solicito uma sessão ao NHibernate na chamada de OpenSession onde poderei persistir meus objetos sem me preocupar com a estrutura ou linguagem do banco de dados.
Vamos a um exemplo:

using System;
using Dominio;

namespace ConsoleFunilaria
{
class Program
{
static void Main(string[] args)
{
var repositorioClientes = new RepositorioClientes();
var cliente = new Cliente
{
Nome = "Bruno Costa",
CPF = 98765432100,
Email = "brunocosta@refatorando.wordpress.com"
};

repositorioClientes.Salvar(cliente);
Console.WriteLine("\n\nCódigo do cliente: {0}", cliente.ID);
}
}
}


Por hora era isso pessoal, espero que tenha sido claro!
Se alguém estiver afim comente, isso vai ajudar os próximos posts ficarem melhores.
Até a próxima!

Anúncios

Sobre estudos e provas de conceito

16/04/2012

A poucos meses tive a oportunidade de participar de uma fase quase mítica em um projeto:

O pré-game

Pode ser chamado de análise técnica, modelagem de ambiente entre outras coisas.
O importante é que nessa fase serão feitos estudos e provas de conceito (POC’s) afim de se definir uma base arquitetural para o projeto.
Bacana não? Quantas vezes você dispôs desse tempo?

A questão aqui é:

Como aproveitar bem esse tempo?

Bem, como esse foi meu primeiro posso apenas te falar com base nos frutos que estou colhendo (alguns amargos).
Vai que um prégame caía no seu colo!

Então:

  • Não desperdisse esse tempo!
    Foque em soluções para reduzir o impacto. Teste opções para seus maiores problemas. Levante prós e contras tentando ser imparcial. Dívida sempre os resultados com seu time.
  • Alinhe o conhecimento!
    Projetos grandes tem equipes grandes, logo você encontrará estilos distintos em seu projeto. Faça mini-palestras com os resultados anteriores colocando a equipe para decidir como utilizar uma solução/recurso.
  • Estude mesmo!
    Ao apresentar uma opção você tem que estar preparado para as perguntas. E se for aceita sua opção deve estar apto  defende-lá no futuro quando questionado sobre como escolha.
  • Não se apegue!
    Mudanças podem levar a um refactor que mude os motivos de usar sua opção. Leve em conta sempre os saúde da equipe e do projeto. Esse é seu objetivo.

Acha muita responsabilidade para um pre-game?
Pois bem. Seja ousado, talvez essa seja sua única chance!

Como sei se sou junior, pleno ou sênior?

15/10/2011

Por vezes ouvi profissionais questionando:

“Como sei se sou junior, pleno ou sênior?”

Definitivamente essa resposta é relativa. Porém, uma parâmetro que gosto de utilizar para isso é a maturidade do profissional em compreender e colaborar com os problemas impostos. Ou seja, sua capacidade de “tocar” sozinho seu trabalho. Logo prefiro fazer essa pergunta da segunte maneira:

“Qual meu nível de maturidade?” ou ainda ”Qual meu nível de senioridade?”

Li um ótimo post do Elemar Jr falando sobre tipos de liderança, onde esse assunto é abordado pelo outro lado da equipe: O do líder.

Falando sobre equipes auto-gerenciaveis e sobre gestão de acordo com a “maturidade” dos profissonais liderados, ele define quatro níveis de liderança:

  • Direção: Onde um profissional novato precisa ser direcionado e controlado, já que sua falta de domínio ou conhecimento, exige mais cautela. Tornando o profissional mais eficiente e fazendo-o evoluir com mais rapidez.
  • Orientação: Conforme o profissional se sente mais avontade com seus conhecimentos, começa a contribuir com as soluções, mas deve sempre “ouvir” seu líder que emprega uma aprovação ou avaliação de suas opiniões a fim de direcioná-lo a maior maturidade.
  • Delegação: O líder precisa apenas dar condições ao profissional para que um bom trabalho seja feito. Aqui chegamos a senioridade.
  • Apoio: Nesse nível o líder não é mais o indicador de soluções e sim “um conselheiro”. O profissional deve ser ouvido e aconselhado sobre caminhos a seguir, porém, ainda não é um profissional que pode ser deixado sozinho.

Com esses aspectos definidos, proponho uma reflexão:

Como você quer ou precisa ser liderado para fazer um bom trabalho?

A resposta deve te ajudar a encontrar seu nível de maturidade. A dizer quão sênior você pode ser considerado.

É comum ver profissionais reclamando da falta de reconhecimento por parte das empresas, muitas vezes – mas não todas – de maneira prematura, equivocada. Ou ainda profissionais “supervalorizados” por seu tempo de experiência e não por maturidade (não, eles não caminham junt0s). Creio que se conhecer é o primeiro passo para evitar esses dois cenários, que a médio prazo são muito prejudiciais a uma carreira.

Faça uma análise de sua carreira e de sua postura de trabalho e evite cair nessa auto-confiança exagerada que leva muitos a estagnar profissionalmente. E aproveite para ler o post do Elemar (http://elemarjr.net/2011/09/25/nada-to-desigual-quanto-tratar-pessoas-diferentes-de-forma-igual/) e avaliar se sua liderança está de acordo com suas expectativas e capacidades.

Dica: Seja realista com suas avaliações pessoais 😉

E mais um panda morre na china…

12/07/2011

Máxima: Toda vez que um programador diz “é simples” um panda morre na China.

É triste mais é verdade, programadores tem a mania de subestimar requisitos e problemas.

E como acabar com isso em seus projetos? Bem se descobrir me avise…

Porém, incentivar a realidade na equipe seria um bom começo para evitar falhas de comunicação.
Tenho acompanhado e participado de equipes com problemas em estimar tempo e dar prazo e infelizmente isso é bem comum. Mas nem tudo são espinhos, ao longo da minha carreira tento colher as empreitadas onde o prazo e a qualidade foram mantidas e clientes e equipe saem felizes.

E bem, o chutômetro é o método de calculo mais frequente em equipes falhas. E geralmente por simples receio…
Sim por receio de não agradar subestimam o problema/requisito (e matam o pobre panda).
Ai entra a noção de realidade, um mecanismo de medidas é necessário para que você não precise acreditar piamente na mentira inconsciente da equipe e ajudar a equipe  CALCULAR o prazo e não advinha-lo como em um jogo de cartas. A máxima acima é o que eu uso para questionar a realidade de algo que me foi apresentado como “simples de fazer”.

Evitar o receio de errar de alguém é dar-lhe autoconfiança embasada em fatos. Dizer apenas – você tem certeza? – não ajuda. É necessário dar base aos fatos. Relembrar erros e situações parecidas onde a suposta simplicidade se mostrou mais complexa ou levou mais tempo do que estimado.

Para isso novamente é necessário um mecanismo de medidas. Tempos reais, onde o atraso de um tópico não afete o tempo estimado de outro (a famosa bola de neve).
É necessário ser realista!

Equipes de projetos bem sucedidos geralmente podem se auto intitular bem sucedidos. Basta que tenham visão do que foi feito, onde erraram, onde acertaram e principalmente quanto tempo levaram.

Levar essa experiência para o futuro sim é sucesso.

Salvem a cheerleader os pandas, salvem o mundo…

Ao som de Sonatina in G, Op. 36 No. 5, I. Presto e Sonata No. 14 in C sharp minor, Op. 27 No. 2

Por não saber que era impossível, foi lá e fez

02/07/2011

Sempre atribuí essa frase a Douglas Adams por me recordar dela em uma de suas obras da série O Guia dos mochileiros da galáxia, porém, uma pesquisa me mostrou que ninguém sabe ao certo. Alguns dizem que é de Jean Cocteau – cineasta, romancista e ator francês – outros dizem ser de Mark Twain – famoso escritor americano. Notei que pelas datas de nascimento e morte dos três é improvável que a frase seja de Adams como eu imaginava.

Mas de que isso importa? Bem… de nada.

O fato é que essa frase me inspira. E por isso resolvi abrir esse blog com ela.

Pense um pouco, quantas vezes isso já ocorreu? Descobertas científicas, recordes esportivos, quebra de barreiras filosóficas. Só porque alguém não reconheceu aquilo que acreditava como impossível.

E porque não o meu próprio ponto de vista! Sobre o mundo, a sociedade, ou simplesmente meu cotidiano. Quais as outras formas de se ver aquilo que faço hoje?

Ok, brisei um pouco, mas esse é o espirito… Viajar pelo tempo, viver o passado e aprender com o futuro tornando o presente mais… presente.

Impossível? Eu não sei…