SyntaxHighlighter

sexta-feira, 23 de agosto de 2013

Spring.NET: Uma introdução



O Spring.NET é um port para a linguagem .NET do famoso Projeto do Framework de integração, o Spring, da empresa SpringSource, atualmente uma empresa do grupo VMWare, para a linguagem Java, tal framework já é bastate consolidado no meio Java até por, na época de sua criação, implementar tecnologias que a linguagem não tinha como padrão em sua JDK, tecnoogias estas que atualmente já fazem parte de projetos da comunidade principalmente a CDI - Component Dependency Injection, que hoje é uma JSR na comunidade Java, sendo largamente implementada agora na versão 6 de seu JDK. O Spring Framework também deu início ao Projeto para o Enterprise JavaBeans 3.0 onde utiliza muitos padrões de projeto implementados no Spring Framework e o principal deles é justamente a Injeção de Dependências, sendo esta a base de sua integração. Porém, a mesma tecnologia sendo portada para .NET ainda não teve o mesmo sucesso e nem mesmo a mesma quantidade de adeptos.
Muito disso se deve a existência de outros frameworks e conteineres para injeção de dependências tais como: Ninject, Castle Windsor dentre outros já bastante conceituados no mundo .NET. O Spring.NET pode facilmente ocupar este espaço por ser um framework de "curta curva de aprendizado" o que implica que o mesmo é bem mais fácil de se aprender e de se executar e também, a injeção de dependências. A Injeção de Dependências é apenas um de seus vários módulos e é a sua base principal. Diante disso o Spring.NET tira toda a sua vantagem diante dos outros frameworks de Injeção de dependências porque o Spring.NET não faz só este trabalho, faz mais do que isso: integra desde Camada de Acesso a Dados à Camada de Apresentação, bem como Queue Messaging, WebServices, Integração com WCF e por aí vai, utilizando o Spring.NET como integrador de suas aplicações, ele permite e garante a estabildade permitindo ao desenvolvedor que não se preocupe com a sua infraestrutura: coleta de lixo, instanciação de objetos, performance e escalabilidade. Qual seria a vantagem de se usar o mesmo framework para Integrar todas as camadas? creio que todo desenvolvedor ou Arquiteto procura algo deste porte para sua aplicações, o que será decisivo para o uso ou não do Spring.NET será apenas a arquitetura e principalmente o custo e o tempo do Projeto. Entendendo bem como funciona a Injeção de Dependências, o desenvolvedor consegue dominar o Spring.NET por completo.

Os Módulos do Spring.NET
O Spring.NET detém 18 módulos de Integração que participam de todo o ciclo de vida de um projeto: de sua análise até os teste finais para entrega do software. Vamos listá-los:
- Arquitetura de Base
Esta arquitetura é a que sustenta o Spring.NET e sobre ela que as integrações são executadas.
1) Core - Núcleo principal que é utilizado como Container para Injeção de Dependências e as funcionalidades principais, que são as interfaces de uso para esta infraestrutura de Injeção.
2) AOP - Aspect Oriented Programming - Programação Orientada a Aspectos contendo suas Suporte a Modelo AOP, Infraestrutura utilizando o Padrão de Projetos Proxy e a Biblioteca Aspect Library. O Spring.NET é um dos poucos frameworks que pode ser utilizado como container AOP também, esta tecnologia na linguagem Java já é bastante consolidada e utilizada, por isso ela também foi trazida para o Spring.NET para que suas facilidades em Projetos também sejam exploradas pelas Equipes que utilizam o .NET.
- Arquiteturas implementadas pelo Spring.NET para integração.
São as arquiteturas de integração propriamente ditas na qual o Spring disponibiliza tendo esta integração sempre facilitada pela Injeção de Dependências. Temos os seguintes módulos:
a) Camada de Dados (Gerenciamento de Transação): NHibernate;
b) Mensageria (Messaging) (Utilizando sempre através do Microsoft MSMQ): Apache NMS, Tibco EMS;
c) Serviços (Abstração de Serviços Portáveis, ou seja, WebServices, SOA e afins): Enterprise Services, Web Services e Serviços WCF.
d) Camada de Apresentação: MVC
e) Teste Unitário: NUnit e MSTest
f) Scheduling ou Agendamento de Tarefas: Quartz.NET
Neste artigo, vamos implementar a Arquitetura básica e o Módulo de Core. Em artigos futuros falaremos de todos os Módulos e arquiteturas.


Imagem 1. Módulos do Spring.NET


A Imagem 1 nos dá uma impressão do tamanho deste framework e suas implementações internas.

Injeção de Dependências com o Spring.NET

O Spring.NET e seu assembly Spring.Core implementam a Injeção de Dependências utilizando os dois tipos existentes: via Setter e via Construtor. Tomemos como exemplo uma Classe que fará a persistência de um Cliente e uma Classe que será responsável por abrir a conexão com a Base de Dados. Para este exemplo usamos as Classes respectivamente: ClienteDAL e Conexao. Estas duas Classes nos farão compreender melhor os dois tipos de Injeção de Dependências existentes e como estes são utilizados pelo Spring.NET.
Injeção de Dependências via Construtor
Neste tipo de Injeção, A Classe injetada estará encapsulada dentro de um parâmetro que será passado ao construtor, lembrando que este parâmetro deve ser tipado com a Classe a ser injetada, como mostram os Trechos de Código 1 e 2:

Trecho de Código 1. Classe Conexao
 public class Conexao{ 
  #region Construtor
  //Digitando ctor e pressionando a tecla TAB duas vezes
  //O Visual Studio cria um construtor padrão      
  public Conexao() 
  {
     //Algoritmo para acesso ao Banco de Dados
  }
  #endregion
 }

Esta nossa Classe Conexão fará o acesso ao Banco de Dados e será necessária em nossa classe de persistência. Esta será injetada no construtor da Classe ClienteDAL via parâmetro tipado como Conexao. Como mostrado no Trecho de Código 2.

Trecho de Código 2. Injeção da Classe Conexão no construtor de ClienteDAL 
#region Propriedades
        /// <summary>
        /// Propriedade que será utilizada para Injeção via Construtor
        /// </summary>
        public Conexao conector { get; set; }
        #endregion

        #region Construtores

        public ClienteDAL()
        {

        }

        /// <summary>
        /// Construtor para Injeção de Dependências 
        /// via Construtor
        /// </summary>
        /// <param name="conexao"></param>
        public ClienteDAL(Conexao conexao)
        {
            this.conector = conexao;
        }
#endregion
 

Neste ponto, observando o construtor da classe ContatoDAL, podemos notar que o parâmetro chamado conexao está tipado com a nossa Classe Conexao, logo já temos a nossa injeção de dependências pronta para uso, o Spring.NET utiliza do padrão singleton juntamente com o Service Locator, ou seja, abre apenas uma instância desta Classe diretamente, caso a mesma não esteja instanciada, ela o é automaticamente, sempre que o construtor é ativado. O que torna o uso bastante racional. Pronto, agora você já pode usar seus métodos de persistência preocupando-se apenas com as operações de CRUD.
Injeção de Dependências via Setter
Nesta modalidade de Injeção de Dependências, utilizamos um "setter" para que nele possamos Injetar a Classe que proverá todo o serviço necessário. Como podemos ver no Trecho de Código 3.
Neste modo, podemos utilizar uma interface para enriquecer a nossa codificação, posto que no momento da implementação da Injeção, podemos fazer com que a Classe Injetada possa utilizar a interface facilitando a abstração em um ambiente de “Mundo Real”. Neste momento, vamos utilizar esta Injeção via Setter em uma Classe de Regra de Negócio que irá utilizara a Interface IClienteDAL para prover a injeção de dependências para ClienteDAL


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

using IntroSpringNet.Modelo;

namespace IntroSpringNet.Persistencia
{
    public interface IClienteDAL
    {
        void Salvar(Cliente cliente);
    }
}

Agora que criamos a nossa interface, vamos criar usar um trecho de código para exemplificar esta injeção.
#region Propriedades

public IClienteDAL DAL { get; set; }

#endregion

#region Métodos

public Boolean CadastrarCliente(Cliente cliente)
{
  DAL.Salvar(cliente);
  return true;
}

#endregion


Podemos ver na que a propriedade DAL recebe a Interface IClienteDAL onde receberá a injeção de ClienteDAL. A Classe CadastrarCliente, utiliza DAL e não há a necessidade de instanciar o objeto, posto que o Spring já está controlando o objeto em seu contêiner via setter.
Como o Spring gerencia os Objetos para a DI.
O Spring.NET tem uma forma peculiar de gerenciar seus objetos, todos estes objetos são registrados em um arquivo .xml, ele pode ser os descritores do próprio .NET, ou seja, os arquivos .config – App.Config se standalone ou Web.Config se Web. Pode-se utilizar estes arquivos ou neste arquivos fazer um apontamento para outro XML, posto que o Spring.NET tem um cabeçalho bem peculiar, no Trecho de Código 4, temos um exemplo de arquivo .XML com header e configuração de gerência de objetos registrados. Sem este arquivo, o Spring.NET não poderá funcionar posto que nele estão todas as funcionalidades necessárias para que o contêiner seja inicializado e que o mesmo reconheça todos os objetos através do parsing, ou seja, o arquivo é totalmente validado antes de ser utilizado

Trecho de Código 4. Configuração do Spring.NET em arquivo de configuração XML
<configSections>
    <sectionGroup name="spring">
      <section name="context" type="Spring.Context.Support.ContextHandler
               , Spring.Core"/>
      <section name="objects" type="Spring.Context.Support.DefaultSectionHandler
               ,Spring.Core"/>
    </sectionGroup>
  </configSections>
...
<spring>
    <context>
      <resource uri="config://spring/objects" />
    </context>
    <!-- Objetos para Injeção de Dependências -->
    <objects xmlns="http://www.springframework.net">
      <!-- Conexao -->
      <object name="Conexao" type="DAL.FonteDeDados.Conexao, DAL"/>
            
      <!-- ContatoDAL -->
      <object name="ContatoDAL" type="DAL.Persistencia.ContatoDAL, DAL">
        <constructor-arg ref="Conexao"/>
      </object>
      
      <!-- ManterContato -->
      <object name="ManterContato" type="BLL.Negocio.ManterContato, BLL">
        <property name="Dao" ref="ContatoDAL" />
      </object>
      
    </objects>
  </spring>
...

Dentro da tag configSection no início do arquivo, temos a tag sectionGroup, dentro desta temos mais dois sections com o atributo de name, estes atributos significam que neste arquivo temos o acesso ao Contexto e que nele também existem objetos a serem gerenciados pelo Conteiner de Injeção de Dependências. Com relação ao Contexto, significa que temos de chamar a interface IApplicationContext dentro de nossa aplicação para que o Spring.NET possa acessar as configurações deste arquivo para iniciar o contêiner de Injeção de Dependências.
Na seção que contêm a tag de nome Spring, temos a configuração e registro dos objetos que serão utilizados pelo contêiner de DI. Veremos este trecho mais de perto através do Trecho de Código 5.

Trecho de Código 5. Seção de Configuração do Spring e seus objetos
<spring>
    <context>
      <resource uri="config://spring/objects" />
    </context>
    <!-- Objetos para Injeção de Dependências -->
    <objects xmlns="http://www.springframework.net">
      <!-- Conexao -->
      <object name="Conexao" type="DAL.FonteDeDados.Conexao, DAL"/>
            
      <!-- ContatoDAL -->
      <object name="ContatoDAL" type="DAL.Persistencia.ContatoDAL, DAL">
        <constructor-arg ref="Conexao"/>
      </object>
      
      <!-- ManterContato -->
      <object name="ManterContato" type="BLL.Negocio.ManterContato, BLL">
        <property name="Dao" ref="ContatoDAL" />
      </object>
      
    </objects>
  </spring>
Nesta seção, a tag context logo abaixo do inicio da seção completa o que está presente na configSection do Trecho de Código 4, onde temos o atributo chamado object. Ambas context e resource estão interligados a esta configSection.
Com relação aos objetos gerenciados pelo Spring se encontra dentro da tag object que é registrada através de objects  onde tem o nome de serviço apontando para HTTP://www.springframework.net, neste momento, iniciando o registro das Classes no contêiner de DI do Spring.
Cada tag object contém alguns atributos, sendo os mais importantes name e type. Name recebe um valor qualquer, como uma identificação, ela não precisa ser igual ao nome da Classe, mas por convenção o segue apenas para questões de documentação caso existam muitos em um arquivo de gerenciamento. Já type, somos obrigados a colocar o nome completo da classe, seguido de uma virgula (,) e o nome do assembly,como visto no Trecho de Código 6.

Trecho de Código 6. Um objeto simples registrado.
<!-- Conexao -->
<object name="Conexao" type="IntroSpringNet.Persistencia.Conexao, IntroSpringNet"/>
O objeto em questão significa que para o Conteiner a Classe DAL.FonteDeDados.Conexao no Assembly DAL foi registrada com o nome de Conexao
 Caso a tag object só tenha estes registros signfica que é apenas uma Classe sendo apontada e nada mais. Porém, quando fazer as injeções via setter ou via Construtor precisamos colocar mais uma tag dentro de object para informar ao Spring que dentro desta Classe gerenciada, o contêiner ainda precisa efetuar a Injeção de Dependencias. No Trecho de Código 7, vemos um exemplo de Injeção via Construtor das classes criadas nos Trechos de Código 1 e 2.

Trecho de Código 7. Injeção via construtor registrada no arquivo de configuração do Spring.NET
<!-- ClienteDAL -->
<!-- Injeção via Construtor -->
<object name="ClienteDAL" type="IntroSpringNet.Persistencia.ClienteDAL, IntroSpringNet">
<constructor-arg ref="Conexao"/>
</object>
Este objeto registrado no Trecho de Código 7 pela sua implementação nos mostra que não é um objeto simples, na tag constructor-arg significa que a Classe informada tem um construtor e que o parâmetro injetado é a classe registrada com o nome de Conexao, pois ref significa “fazer referência a um objeto registrado no container”. Então caso a interface IApplicationContext registre o objeto de nome ClienteDAL, ele automaticamente registrará dentro da Classe ClienteDAL, em seu construtor o tipo do argumento será a classe que está atrelada ao nome Conexao e para nosso entendimento é o mesmo objeto registrado no Trecho de Código 6, ou o nosso objeto simples.
A diferença no registro via setter é que ao invés de constructor-arg apenas chamamos a tag property, apontando a propriedade onde a Classe é injetada no setter. Como nos mostra o Trecho de Código 8.

Trecho de Código 8. Injeção vai Setter registrada no contêiner do Spring.NET
<!-- ManterContato -->
<!-- Injeção via Setter -->
<!-- Injeta ClienteDAL dentro de DAL
 DAL é tipada pela interface, logo a mesma é preenchida por ClienteDAL
-->
<object name="ManterCliente" type="IntroSpringNet.Negocio.ManterCliente, IntroSpringNet">
  <property name="DAL" ref="ClienteDAL" />
</object>

Este objeto informa que a propriedade DAL receberá a injeção do objeto ClienteDAL mostrado no Trecho de Código 7.

Implementação do Acesso aos Objetos

Agora faremos com que todas estas configurações acima funcionem plenamente. Neste trecho, vamos utilizar a fachada IApplicationContext do Spring para acessar o contêiner de Injeção de Dependências. Como no exemplo do Trecho de Código 8.


Contato contato = new Contato();
contato.NomeCompleto = "Luis Gabriel Nascimento Simas";
contato.Email = "gabrielsimas@gmail.com";
contato.Linkedin = "http://br.linkedin.com/in/gabrielsimas/";
contato.Twitter = "@gabnascimento";
contato.Facebook = "http://www.facebook.com/luisgabrielsimas";

IApplicationContext di = ContextRegistry.GetContext();
IContatoDAL dal = (ContatoDAL)di.GetObject("ContatoDAL");

dal.Salvar(contato);

Em di, lemos o arquivo de configuração, em dal, carregamos o objeto gerenciável do arquivo de configuração que contém o id contendo o valor “ContatoDAL”, o mesmo objeto do Trecho de Código 7.

Conclusão

Neste artigo bastante introdutório sobre o Spring.NET, vimos um pouco de sua base principal, que é a Injeção de Dependências, em artigos futuros falaremos de cada um dos módulos do Spring.NET de forma bastante prática. 

Referências
Spring.NET Framework - http://www.springframework.net/
Documentação do Spring.NET - http://www.springframework.net/documentation.html
Injeção de Dependências/DI de Martin Fowler - http://www.martinfowler.com/articles/injection.html

Introdução ao NHibernate



Neste post, mostrarei uma pequena introdução ao NHibernate que é um framework de ORM portado para a plataforma .NET originário do framework Hibernate, um framework de bastante sucesso e utilizado até então, para a linguagem Java. Diante deste port, o NHibernate ainda é um projeto novo em constante evolução, tanto que ainda não acompanha seu “irmão” mais famoso com as grandes facilidades e opções de mapeamento mais rápido, principalmente com o uso de anotações, que em .NET são chamados de atributos – São interfaces que são utilizadas para “decorar” Classes, um substituo dos arquivos XML, tão odiados pelos programadores –que facilitam muito o dia-a-dia.
Tal framework foi criado pela JBoss, criadora do Hibernate, porém, com o tempo foi criada a NHForge que cuida diretamente do controle deste framework em site diferenciado, o NHForge.org.

Estrutura do NHibernate

Vemos a estrutura básica do NHibernate na Imagem 1.
Imagem 1. Diagrama arquitetônico do NHibernate

Na Imagem 1, podemos observar que o NHibernate é acoplado diretamente entre O Banco de Dados a sua aplicação, porém, podemos observar também que os objetos persistentes – persistent objects – são utilizados através da aplicação e, através de conexão com o NHibernate, nos dá a entender que são as peças mais importantes desta engrenagem. Podemos também observar que dentro do domínio do NHibernate vemos o mapeamento em arquivos XML – Seção XML Mappings e o arquivo de configuração do .NET, App.config ou Web.config. Fique certo de que o NHibernate, como uma Camada de Acesso aos Dados e, posteriormente de persistência, de sua aplicação, estão fortemente acoplados porque todas as outras camadas, caso existam, são totalmente dependentes destes objetos de persistência para E/S de dados. Seria muito interessante mostrar uma visão mais detalhada da arquitetura em tempo de execução do NHibernate, porém isso não é possível pelas formas diferentes de abordagens e configurações, destas separamos duas: As arquiteturas simples e detalhada.
Na sua arquitetura simples, faz com que a aplicação disponibilize suas próprias conexões utilizando o ADO.NET e gerencie suas próprias transações. Esta abordagem usa um pequeno conjunto de APIs do NHibernate, como podemos verificar na Imagem 2.

Imagem 2. Subconjunto de APIs do NHibernate


Na arquitetura Detalhada, existe uma abstração da aplicação totalmente diferente do uso das APIs do ADO.NET e deixa o NHibernate controlar e cuidar dos detalhes, permitindo assim que o mesmo cumpra o seu papel de Framework ORM, estes objetos dos quais o NHibernate faz uso internamente mostrados na Imagem 3 e posteriormente explicados um a um.


Imagem 3. Objetos presentes na Arquitetura Detalhada do NHibernate

Abaixo, listamos alguns dos objetos mais importantes presentes na Imagem 3:

ISession (NHibernate.ISession)
Um objeto single-threaded, ou seja, exclusivo por instância, e de curta duração que representa a conversa entre a aplicação e a unidade de persistência. Encapsula uma conexão ADO.NET. É uma factory para ITransaction. Mantém um cache de primeiro nível, mandatório, ou seja, sob demanda, de objetos persistentes. Este cache é utilizado quando o grafo de objetos é utilizado ou busca de objetos por identificador.

Persistent Objects and Collections
São objetos contendo estados de persistência e funções de negócio, tais objetos são sempre de curta duração e single-threaded. Estes podem ser Classes POCO, o que mais importa sobre estes é que são sempre associados com uma, somente uma ISession. Assim que uma ISession é finalizada, eles são desconectados e liberados para serem utilizados por quaisquer camadas na aplicação, isto quer dizer que pode ser utilizados como um DTO para transferência de dados de/para a Camada de Apresentação.

Transient Objects and Collections
Objetos Transientes (de curta duração, não persistidos em Banco de Dados) e Coleções
são instâncias de Classes que não estão atualmente associados com uma ISession. Eles podem ser instanciados ou não pela aplicação e sendo assim não foram ainda persistidos ou podem ser instanciados por uma ISession fechada.

ITransaction (NHibernate.ITransaction)
Esta Interface é opcional. É um objeto utilizado pela aplicação para especificar unidades de trabalho atômicas ou não. Aplica abstração de uma transação encapsulada do ADO.NET. Um ISession pode se utilizar de várias ITransaction em alguns casos.

IConnectionProvider (NHibernate.Connection.IConnectionProvider)
O Uso desta interface é opcional. Uma Factory para conexões e comandos ADO.NET. Aplica abstração de uma implementação específica e concreta de IDbConnection e IDbCommand. Não é exposto para a aplicação, mas, pode ser extendido/implementado pelo desenvolvedor.

IDriver (NHibernate.Driver.IDriver)
Uma interface que encapsula provedores ADO.NET diferentes, tais como convenções para nomes de parâmetros e convenções suportadas para uso com o ADO.NET. Seu uso é opcional.

ITransactionFactory (NHibernate.Transaction.ITransactionFactory)
Uma Factory para instancia de ITransaction. Não é exposta a aplicação, mas pode ser extendida/implementada pelo desenvolvedor. Seu uso é opcional.

Ao usar a arquitetura simples, a aplicação não utiliza nem ITransaction/ITransactionFactory e muito menos IConnectionProvider para utilizar o ADO.NET diretamente.

Neste artigo não utilizaremos todos estes objetos.

Classes POCO para uso com o NHibernate

Existem 4 regras principais para Classes POCO serem “reconhecidas” pelo NHibernate:

1) Use propriedades para campos persistentes.
2) Implemente um construtor padrão, ou seja, vazio.
3) Crie uma propriedade Identificadora, ou Id.
4) Utilize classes que não sejam sealed e use métodos virtuais.

Mapeamento do NHibernate

Atualmente, o mapeamento no NHibernate pode ser executado utilizando um arquivo XML ou com um novo projeto onde são utilizados atributos para decorarem as classes, primeiramente, vamos ao mapeamento utilizando o XML.

Mapeamento por Arquivo XML
O Mapeamento XML é a primeira etapa para a persistência com o NHibernate é onde tudo começa, na Código Fonte 1, temos um exemplo de cabeçalho estável para uso com o NHibernate. Por motivos de compilação, o NHibernate solicita que os arquivos para mapeamento contenham também a extensão .hbm como forma de ser reconhecido pelo assembly do ORM. Estes arquivos precisam ter sua propriedade Build Action setados como Embedded Resource, posto que no momento da compilação do código,  o arquivo seja reconhecido e convertido para um hierarquia de classes utilizando ponto, por exemplo: temos que mapear a Classe Pessoa para persistência, então criamos o arquivo pessoa.hbm.xml e nas suas propriedades, colocamos o atributo Build Action como Embedded Resource, como mostrado na Imagem 3.

Código Fonte 1. Cabeçalho de XML para mapeamento
<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
                   assembly="DAL"
                   namespace="DAL.Entidade">
...
...
...
....
...
</hibernate-mapping>

Como podemos ver na Código Fonte 1, temos 2 atributos na tag hibernate-mapping que são assembly e namespace.
Assembly informa em qual Projeto estão localizadas as Classes a serem buscadas pelo NHibernate no qual está sendo apontada neste arquivo XML.
Namespace é o caminho completo de onde tais classes estão dentro de um Projeto. Lembrando que quanto mais informação neste sentido é menos tempo em que o compilador perde buscando as Classes para Mapeamento em memória.
Imagem 4. Arquivo XML configuração e nomenclatura padrão NHibernate

Neste ponto, já podemos mapear as nossas Classes de Persistência. Não é obrigatório criar um arquivo para cada Classe, podemos em um arquivo só inserir todas, mas, como melhor prática, é bom que seja criado um arquivo para cada Classe, desta forma, o entendimento do Sistema fica melhor e separa bem as responsabilidades. Na Código Fonte 2, temos um exemplo de Entidade na qual vamos mapear via XML.

Código Fonte 2. Classe Carro
public class Carro
    {
        #region atributos

        private Int32 id;
        private String modelo;
        private String motor;

        #endregion

        #region Propriedades

        public virtual Int32 Id
        {
            get { return this.id; }
            set { this.id = value; }
        }

        public virtual String Modelo
        {
            get { return this.modelo; }
            set { this.modelo = value; }
        }

        public virtual String Motor
        {
            get { return this.motor; }
            set { this.motor = value; }
        }

        #endregion

        #region Construtores

        public Carro()
        {

        }

        public Carro(String modelo, String motor)
        {
            this.Modelo = modelo;
            this.Motor = motor;
        }
        #endregion

        #region Sobrescritas
        public override string ToString()
        {
            return this.id + ", " + this.modelo + ", " + this.motor;
        }
        #endregion
    }
}
 

Para o correto mapeamento da Entidade, mapeamos apenas as Propriedades para o arquivo XML, como descrito na Código Fonte 3.

Código Fonte 3. Arquivo XML Carro.hbm.xml
<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
                   assembly="DAL"
                   namespace="DAL.Entidade">

  <class name="Carro" table="Carro">
    <id name="Id" column="id">
      <generator class="identity" />
    </id>

    <property name="Modelo" column="modelo" />
    <property name="Motor" column="motor" />
   
  </class>
 
</hibernate-mapping>

Na Código Fonte 3, temos algumas informações importantes, a tag id significa que estamos mapeando a propriedade de identificação única da Entidade, ou seja, valor exclusivo que identifica os dados gravados na Classe. Dentro desta tag, temos uma tag generator que como no Banco de Dados ela é um tipo de auto incremento, utilizamos o valor de atributo identity. Os valores possíveis e permitidos pela tag generator dentro do atributo class são:

increment - Gera identificadores de qualquer tipo desde que sejam únicos e que nenhum outro processo esteja inserindo dados na mesma tabela. Não use este valor com um Cluster.

identity - Suporta campos do tipo identity, ou seja, auto incremento nos Bancos de Dados DB2, MySQL, MS SQL Server e Sybase. O identificador que é devolvido pelo Banco de Dados é convertido para o tipo da propriedade usando Convert.ChangeType. Qualquer propriedade inteira é permitida.

sequence - Usa uma Sequence criada em DB2, PostgreSQL, Oracle ou um generator do Firebird. O identificador retornado pelo Banco de Dados é convertido para o tipo da propriedade usando Convert.ChangeType. Qualquer propriedade inteira é permitida.

hilo - Usa um algoritmo de hi/lo para gerar de forma bem eficiente qualquer tipo inteiro de qualquer Tabela ou campo (por padrão, hibernate_unique_key e next_hi respectivamente) como uma fonte de valores hi. O Algoritmo de hi/lo gera identificadores que são únicos apenas para um Banco de Dados em específico. Não use este hilo com uma conexão gerenciada pelo usuário, ou seja, quando as threads não são as mesmas.
Você pode usar o parâmetro "where" para especificar um registro usado em uma tabela. Isto é muito útil se você quer usar uma tabela única para seus identificadores, com registros diferentes de cada tabela.

seqhilo - Usa um algoritmo de hi/lo para gerar de forma bem eficiente qualquer tipo inteiro, dada uma SEQUENCE criada no Banco de Dados.

uuid.hex - Usa System.Guid e seu método ToString para gerar identificadores do tipo String. O tamanho da String depende do formato selecionado.

uuid.string - Usa um novo System.Guid para criar um tipo byte[] que é convertido para String.

guid - Usa um novo System.Guid como identificador.

guid.comb - Usa o algoritmo para gerar um novo System.Guid.

native - captura tipos identity, sequence ou hilo dependendo das capacidade existentes no Banco de Dados.

assigned - Deixa a aplicação decidir por um identificador para o objeto antes de Save() ser chamado.

foreign - Usa o identificador de outro objeto associado. Normalmente usado em conjunção com uma associação com chave primária com a tag <one-to-one>

Para a Tag property, não é necessária muita informação, são as propriedades da Classe Carro que refletem os campos da Tabela.

Mapeamento por Anotação/Atributo

Todos nós já sabemos que o NHibernate precisa de mapeamentos efetuados através de arquivos XML para que possa colocar em memória o ORM para a persistência. Para facilitar este trabalho foi criado um Projeto desenvolvido inicialmente por John Morris e que depois passou às mãos de Pierre Henri Kuaté, mais conhecido como KPixel. Este projeto decora as Classes com atributos o que torna o arquivo XML desnecessário posto que o Projeto gera um Stream para a memória como o XML faria, este projeto se chamado NHibernate Attributes que utiliza o assmbly NHibernate.Mapping.Attribute. Um exemplo de Classe mapeada com o assembly NHibernate.Mapping.Attributes na Código Fonte 4.

Código Fonte 4. Classe “decorada” com atributos NHibernate
    [Serializable]
    [Class(Schema = "RevistaArtigo02", Table = "Carro")]
    public class Carro
   
    {
        #region atributos
       
        private Int32 id;
        private String modelo;
        private String motor;

        #endregion

        #region Propriedades
        [Id(Name="Id",Column="id"),Generator(1,Class="identity")]
        public virtual Int32 Id
        {
            get { return this.id; }
            set { this.id = value; }
        }

        [Property(Column="modelo")]
        public virtual String Modelo
        {
            get { return this.modelo; }
            set { this.modelo = value; }
        }

        [Property(Column="motor")]
        public virtual String Motor
        {
            get { return this.motor; }
            set { this.motor = value; }
        }

        #endregion

        #region Construtores

        public Carro()
        {

        }

        public Carro(String modelo, String motor)
        {
            this.Modelo = modelo;
            this.Motor = motor;
        }
        #endregion

        #region Sobrescritas
        public override string ToString()
        {
            return this.id + ", " + this.modelo + ", " + this.motor;
        }
        #endregion
    }
}

Arquivo de Configuração do NHibernate

O Nhibernate é um framework bastante versátil no qual permite que o configuremos via Código ou via arquivo XML, neste artigo vamos abordar o mapeamento via XML, para maiores informações sobre a inicialização do NHibernate via código,e só acessar o site http://nhforge.org/doc/nh/en/index.html#session-configuration. O Nhibernate precisa ser inicializado através da interface ISessionFactory, com ela, todas as Entidades são compiladas e colocadas na memória, assim como os comandos deste arquivo XML são aceitos e colocados em memória aguardando sua execução. Como padrão, o NHibernate aceita como arquivo de configuração contendo a extensão .cfg.xml, normalmente cria-se um arquivo na raiz do Projeto chamada hibernate.cfg.xml. Neste arquivo, registramos inclusive a string de conexão, dialeto envolvido e outras configurações de ambiente. Na Código Fonte 5, vemos um exemplo deste arquivo.

Código Fonte 5. Arquivo de configuração hibernate.cfg.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="connection.driver_class">NHibernate.Driver.SqlClientDriver</property>
   
      <!-- Aqui você deve coloca o seu Connectio String -->
      <property name="connection.connection_string">
        Data Source=ALLSPARK\SQLEXPRESS;Initial Catalog=RevistaArtigo02;Integrated Security=True
      </property>
   
      <property name="dialect">NHibernate.Dialect.MsSql2008Dialect</property>
    <property name="show_sql">true</property>
    <property name="current_session_context_class">thread</property>
  </session-factory>
</hibernate-configuration>

Diante desta informação, já podemos instanciar a nossa ISessionFactory, que funciona como uma fachada. O mais importante é que devemos sempre prezar pela performance, é necessário que criemos uma Classe que gere um Singleton para que o NHibernate possa ser carregado e controlado de forma independente e desacoplada do código, na Código Fonte 6, temos um exemplo de Classe que contém este padrão de Projeto. Esta Classe acessa o arquivo de configuração e faz com que toda a “mágica” do que fizemos até agora aconteça e que faça a conexão com o Banco de Dados

Código Fonte 6. Classe NHibernateUtil
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

using NHibernate;
using NHibernate.Cfg;

namespace DAL.Reuso
{
    public sealed class NHibernateUtil
    {
        #region Atributos

        private static readonly ISessionFactory fabricaDeSessao;
        private const String CodSessaoAtual = "nhibernate.current_session";

        #endregion

        #region Construtor

        static NHibernateUtil()
        {
            try
            {
                ISessionFactory fabrica = new Configuration().Configure().AddAssembly("DAL").BuildSessionFactory();
               
            }
            catch (Exception)
            {
               
                throw;
            }
        }

        #endregion

        #region Métodos de Controle

        public static ISession PegaSessaoEmUso()
        {
            ISession sessao = fabricaDeSessao.GetCurrentSession();

            if (sessao == null)
            {
                sessao = fabricaDeSessao.OpenSession();
            }

            return sessao; 
        }

        public static void FecharSessao()
        {
            ISession sessao = fabricaDeSessao.GetCurrentSession();

            if (sessao != null)
            {
                sessao.Close();
            }
        }

        public static void FecharFabricaDeSessao()
        {
            if (fabricaDeSessao != null || !fabricaDeSessao.IsClosed){
                fabricaDeSessao.Close();
            }
        }

        #endregion

    }
}

Esta Classe, o leitor pode já utilizá-la como está em seus projetos e até aprimorá-la mais para que fique mais genérica a seu uso, assim como em futuros artigos que faremos de forma mais prática demonstrando o uso de Generics, Fachadas e outros padrões de projeto que facilitem a implementação nos projetos de nossos leitores. Já criamos uma Classe que irá e muito facilitar o nosso trabalho de acesso a base de dados, diante disto, vamos mostrar a melhor forma de utilizá-la.

Acessando a Base de Dados através do NHibernate

Criamos na Código Fonte 6 uma Classe para acesso a Base de Dados, agora, veremos como que NHibernate se comunica com a Base de Dados para permitir que a persistência seja efetuada.
Inicialmente, como uma melhor prática, o NHibernate trabalha com transações, esta é uma forma bem segura de trabalho, posto que caso algo dê errado, um Rollback pode ser dado, caso contrário, um commit grava as alterações no Banco de Dados e a conexão é finalizada, salvo para operações de busca, onde a sessão continua em aberto. Devemos ter isso me mente até mesmo quando o projeto solicitar que utilizemos mais de uma Classe em uma transação. O Nhibernate abre uma transação, efetua o trabalho que precisa fazer, trata este trabalho, caso execute com sucesso, executa um commit, caso não executa um Rollback e posterimente fecha a sessão. Uma Sessão é composta de Transação, execução e Fechamento, o fechamento pode ser um finally com um comado de fechamento ou simplesmente uma execução de operações, neste caso, por exemplo, seria um INSERT, UPDATE e DELETE suficientes para fechar a Sessão o que também não seria necessário que a fechássemos, um fragmento deste trabalho, pode ser visto na Código Fonte 7 já com o uso de nossa Classe NHibernateUtil.

Código Fonte 7.NHibernate interagindo com o Banco de Dados
        public void Gravar(Carro carro)
        {
            ISession sessao = NHibernateUtil.PegaSessaoEmUso();
            ITransaction transacao = sessao.BeginTransaction();

            sessao.Save(carro);
            transacao.Commit();

            NHibernateUtil.FecharSessao();
        }

    }

Como sabemos, o Banco de Dados isola as operações através das transações, diante disso, temos um singleton abrindo e fechando a sessão de forma protegida.
Agora, é só criar um Projeto e implementar a solução. E isso é assunto para um outro artigo.

Conclusão

O NHibernate é mais uma opção frente aos outros frameworks ORM existentes no mercado, ele não perde em nada com relação ao Microsoft ADO.NET Entity Framework e outros. Vimos neste artigo o poder deste framework que já faz bastante sucesso no meio Java e que pode também fazer bastante sucesso no mundo .NET. Vimos apenas 20% de todo o framework e com esta informação, já podemos trabalhar em um Projeto de médio porte. Em artigos próximos, vamos falar de outras partes do NHibernate. Este por ser um framework um tanto extenso se fizéssemos aqui a cobertura deste, com certeza ficaria cansativo ao leitor.

Fortaleça sempre o trabalho em equipe porque sozinho nada se consegue neste mundo, é um prazer tê-lo como leitor.

Forte Abraço

sexta-feira, 16 de agosto de 2013

VB.NET - Module

Em nosso primeiro artigo sobre VB, vamos falar sobre seus conceitos básicos, diante disso, vamos começar por Module, por ser o trecho de código mais elementar no VB.NET, mais adiante veremos outras formas de codificação como Classes, tipos e afins.

A palavra chave Module define um tipo de classe, com algumas exceções. Primeiro de tudo, qualquer função pública, subrotina, propriedade ou variável de instância ou membro definido dentro do escopo de um Module é definido como um membro compartilhado, ou seja, pode ser utilizado globalmente em sua aplicação, este tipo de membro definido permite ao desenvolvedor simular um escopo global dentro de sua aplicação. Abaixo, vemos a estrutura principal e padrão de um módulo, este é o Módulo principal de uma Console Application gerada pelo Visual Studio:

Module Module1 
 Sub Main()
 End Sub 
End Module 

Vamos então, utilizar um projeto com o Module, em seu Visual Studio, crie na sua Solution um Projeto Console Application no VB com o nome DivertindoSeComModule e digite o código como no Trecho de Código abaixo:

Module Module1

    Sub Main()
        'Executa a subrotina MostraBanner
        MostraBanner()

        'Pega o nome do usuário e diz "Olá"
        ApresentaUsuario()

        Console.ReadKey()
    End Sub

    Sub MostraBanner()
        Dim currColor As ConsoleColor = Console.ForegroundColor

        'Muda a cor do texto para amarela
        Console.ForegroundColor = ConsoleColor.Yellow

        Console.WriteLine("*** Bem vindo ao nosso primeiro projeto em VB ***")
        Console.WriteLine(" Este programinha simples, ilustra o papel ")
        Console.WriteLine("do Tipo Module")
        Console.WriteLine("*************************************************")

        'Devolve a cor original
        Console.ForegroundColor = currColor
    End Sub

    Sub ApresentaUsuario()
        Dim userName As String
        Console.Write("Entre com o seu nome: ")
        userName = Console.ReadLine()
        Console.WriteLine("Olá {0}. É um prazer tê-lo conosco.", userName)
    End Sub

End Module

Este programa ao ser executado, pressionando F5, retornará a seguinte saída:


"*** Bem vindo ao nosso primeiro projeto em VB ***
Este programinha simples, ilustra o papel
do Tipo Module
*************************************************
Entre com o seu nome: Luis Gabriel N. Simas
Olá Luis Gabriel N. Simas. É um prazer tê-lo conosco."


Projetos com Multiplos Modules

Em nosso exemplo atual, mostramos que o método Main() pode acessar diretamente os métodos MostraBanner e ApresentaUsuario. Porque estes métodos estão definidos dentro do mesmo Module junto com Main(), não é necessário que coloquemos como prefixo destes métodos o nome de Module1. Porém, caso precise fazê-lo, precisamos refatorar Main() como segue:

Sub Main()
        'Executa a subrotina MostraBanner
        Module1.MostraBanner()

        'Pega o nome do usuário e diz "Olá"
        Module1.ApresentaUsuario()

        Console.ReadKey()
    End Sub

No trecho acima, é completamente opcional esta sintaxe (não influencia nem mesmo na performance). Mas, digamos que vamos precisar criar um novo Módulo em nosso Projeto - chamado MeuModulo - dentro do mesmo arquivo .vb que cria um método parecido com o ApresentaUsuario de Module que contém a Main():

Module MeuModulo
 Public Sub ApresentaUsuario()
  Console.WriteLine("Olá Usuário Maroto...")
 End Sub
End Module

Agora, se você quiser chamar ApresentaUsuario de MeuModulo de dentro da Main(), aí sim você vai precisar colocar como prefixo explicitamente o nome do Módulo. Caso isso não aconteça, o método Main irá procurar por Module.ApresentaUsuario, se este método existir o compilador não retornará erro, mas caso não exista, teremos problemas. Vejamos abaixo a forma de chamada correta do método Main():

Sub Main()
        'Executa a subrotina MostraBanner
        MostraBanner()

        'Pega o nome do usuário e diz "Olá"
        MeuModulo.ApresentaUsuario()

        Console.ReadKey()
    End Sub

Novamente, para fixar: que um único projeto que define muitos Modulos não é necessário que se use o nome do Módulo como prefixo dos métodos que serão utilizados a não ser que os nomes sejam ambíguos assim como no caso do método ApresentaUsuario que existe em Module1 e MeuModulo, neste caso sim, precisamos informar ao compilador qual é o correto do contrário, Main() pegará de seu Module1.
Então, vamos criar mais um Módulo neste nosso projeto atual, chamado ModuloMatematico, como segue:

Module ModuloMatematico
    Function Soma(ByVal x As Integer, ByVal y As Integer)
        Return x + y
    End Function

    Function Subtracao(ByVal x As Integer, ByVal y As Integer)
        Return x - y
    End Function

End Module

Como estamos no mesmo Projeto, basta colocar o nome Soma no metodo Main() de Module1 que ele irá funcionar corretamente:

Sub Main()
        ...
 ...
 'Soma dois numeros
 Console.WriteLine("O resultado da soma é {0}.",Soma(2,2))
 
 'Subtrai dois Números
 'Colocar o nome do módulo como prefixo neste caso, é opcional 
 'É apenas uma demonstração de generalidade
 Console.WriteLine("O resultado da subtração é {0}", ModuloMatematico.Subtracao(2,2))
        Console.ReadKey()
    End Sub

Não se preocupe com relação a explicação de o que é uma Function e o que significa o ByVal, posto que mais adiante, estarei escrevendo um artigo sobre Funções e Subrotinas com VB.NET.

Módulos não são "instanciáveis"

Outra regra do tipo Module é que ele não pode ser diretamente criado usando a palavra new - qualquer tentativa de fazê-lo irá retornar em erro de compilação. Como o trecho abaixo irá retornar em erro:

'Isto não existe no .NET Framework 4.0
Dim m as New Module1()

Uma melhor explicação é que um Módulo apenas expõe membros compartilhados.

Membros dos Módulos

Para incrementar nosso estudo sobre Tipos de Módulos, saiba que módulos podem ter membros adicionais além de apenas subrotinas e funções. Se o leitor amigo quiser definir campos tais como propriedades ou eventos, você é livre para fazê-lo. Por exemplo, você precisa atualizar MeuModulo para receber uma única parte de um dado contendo uma String publica. Veja que o método ApresentaUsuario() agora irá imprimir este valor quando solicitado:

Module MeuModulo
 Public ContaUsuario As String
 Public Sub ApresentaUsuario()
  Console.WriteLine("Olá {0}",ContaUsuario)
 End Sub
End Module

Agora, vamos implementar o método refatorado:

Sub Main() 
 ... 
 'Grava o nome do usuário e chama ApresentaUsuario
 ContaUsuario = "Fred" 
 MeuModulo.ApresentaUsuario() 
 ... 
End Sub

Este foi o nosso primeiro artigo sobre VB.NET como prometido para os nossos leitores que precisam aprender e dominar tal linguagem, primeiramente, vamos explicar e detalhar o básico da linguagem sem muita firula, porque muito material sobre programação fala do be-á-bá que chega a ser cansativo, tentei ser o mais sucinto possível e sempre usando um Projeto por artigo.

Valorize sempre o trabalho em equipe porque não se consegue atingir nenhum resultado sozinho.

Obrigado por visitar o Blog, é um prazer tê-lo como leitor e até o próximo artigo.

quinta-feira, 15 de agosto de 2013

Uma idéia para um Sistema de Vendas online

Como o Blog é jovem e a minha idéia é fazê-lo bem democrático, mas também muito polêmico, posto que de que adianta ficar colocando artigos "água com açúcar" por aqui, artigos mais simples vão servir apenas para os leitores que precisam de algo rápido e bem organizado para resolver os seus problemas do dia a dia, isso acontece muito comigo também e foi pensando nisso e também para que este Blog seja sempre visitado e encontrado por todos os leitores que são entusiastas, profissionais, curiosos, loucos e afins, enfim, toda a gama de leitor que goste ou que queira aprender a programar utilizando como exemplos os projetos do mundo real posto que se fosse de outra forma, qual a graça teria em se criar um Weblog sobre desenvolvimento? pois é, nenhuma.
O título desta postagem ficou bastante vago, ele ficou vago principalmente porque a primeira situação é que não vou usar apenas uma linguagem de programação, mas sim Java, C# e VB.NET e cada uma delas têm as suas peculiaridades, não é mesmo? inicialmente, vamos fazer uma listagem do quê vamos usar, ou seja, a arquitetura, mas de antemão já informo a vocês que vou usar o Oracle como Banco de Dados até para sair um pouco do padrão do MySQL no Java, que agora está sendo substituído pelo MariaDB - os criadores do My depois que o venderam para a Oracle, estão criando outro produto de sucesso, vamos ver para quem vão vender e por quanto -, no .NET (seja C# ou VB) o uso do SQL Server é o padrão.
Mas, para deixar o pessoal mais à vontade, eu vou usar Triggers, Stored Procedures, Functions, Sequences e outros objetos com o Oracle e posso fazer o mesmo utilizando o Microsoft SQL Server 2008 R2 como uma forma de treinar o Leitor para aplicar as Regras de Negócio também no Banco de Dados e acioná-los via Regra de Negócio do Sistema.

O que é necessário para um Sistema de Vendas online?
Bem, de acordo com uma necessidade, um Sistema de Vendas online é dividido em duas partes: a Frente de Loja e a Retaguarda.
Na Frente de Loja, ocorre toda a interação com o cliente, ou seja, a home onde o cliente escolhe o produto, lista o produto, faz a compra, faz o pagamento e etc. A parte de interação com o cliente.
Já a Retaguarda é a parte mais importante para o setor administrativo, é nele que são calculados o lucro, o estoque, as comissões e a geração dos relatórios em tempo real.
No levantamento de Requisitos, temos as seguintes funções da Frente de Loja:

  • Venda de Produto;
  • Busca de Produto;
  • Emissão de Pedido;
  • Integração com gateway de pagamento;
  • Cadastro de cliente;
Temos na Retaguarda, as seguintes funções, iniciais claro, podemos adicionar algo durante o desenvolvimento:
  • Controle de Estoque;
  • Controle de Pedidos;
  • Controle de Vendas;
  • Controle de Entrega de Produtos;
  • Controle Logístico;
  • Controle de Comissão para Vendedores;
  • Relatórios Diversos;
Inclusive, a Frente de Loja, em algumas funcionalidades, faz acesso à Retaguarda, como podemos ver no caso da Venda de Produto e o Controle de Estoque que estão ligadas.
Cada uma destas funcionalidades será melhor abstraída com o intuito de se criar um Diagrama de Casos de Uso ou uma seleção de Estórias de Usuário para criar um Backlog de Produto caso usemos Scrum para controle de nosso cronograma.
No levantamento dos requisitos, já temos um noção do que vamos precisar na Arquitetura.
Vamos precisar criar uma Camada intermediária para controlar a Frente de Loja e a Retaguarda e eu vou chamar esta Camada de Centro de Comando e Controle da Aplicação, nela poderemos fazer a interligação entre a Camada de Frente de Loja e a Camada de Retaguarda.
Já temos uma noção de como vamos começar a separar as partes importantes do Sistema, agora vamos verificar as permissões de segurança.

Permissões e Segurança
Os atores desta nossa trama e dos nossos Casos de Uso e Estórias de Usuário são: o Cliente, o Administrador e o Funcionário.

O Cliente é o responsável por fazer as compras e interagir com a Frente de Loja.
O Administrador é o responsável pelos cadastros dos produtos que são efetuados na retaguarda.
O Funcionário é o responsável pela extração dos Relatórios, Controle de Entrega de Produtos, Controle Logístico, Controle de Comissão dos Vendedores ou Afiliados.

Arquitetura para o Java
Cenário 1:
Para Persistência, vamos usar o Hibernate 3, até para que possamos fazer um Projeto de Migração para Hibernate 4.
Para Mapeamento das Entidades vamos utilizar o JPA 2 com NamedQuery e Anotações.
EJB 3.1 para Injeção de Dependências e componentização, vamos criar os módulos de Frente de Loja e Retaguarda
Para a Camada de Apresentação vamos utilizar a Web com o Primefaces com JSF 2
Para a Camada de Segurança e Controle de Acesso, podemos utilizar o Spring Security.
O Container que iremos utilizar será o GlassFish.

O Spring será usado apenas seu Módulo de Segurança, posto que o EJB já faz o trabalho de Injeção de Dependências.

Cenário 2:
Persistência: Hibernate 3
Mapeamento das entidades será feita com JPA 2 com NamedQuery e Anotações.
Arquitetura MVC utilizando ManageBean
Camada de Apresentação: JSF com PrimeFaces 

Bonus:
WebServices para consumo e acesso de Dispositivos Móveis.
Restful Services para consumo de dispostivios Móveis.
Aplicativo para iPad compatível com a Loja.
Aplicativo para Android compatível com a Loja.
Barramento utilizando o Mule que é um Enterprise Service Bus gratuito.

Todos os cenários serão forçosamente utilizados os padrões de Fachada, Service Locator, Business Delegate e principalmente o uso dos tipos Genéricos com o Java. Deixando bem claro que tais padrões são obrigatórios dentro do EJB, caso não sejam utilizados, o modelo não será certificado. Vamos abusar do Ajax.

Arquitetura para o .NET

- Persistência com NHibernate (projeto de atributos como annotations no Java)
- Container de IoC com Spring.NET
- Na Camada de Apresentação vamos utilizar o ASP.NET MVC 4 com o Razor.
- Desenvolvimento será efetuado em 3 camadas: DAL (Camada de Dados), BLL (Camada de Regra de negócios) e Apresentação.

Bonus:
Integração com dispositivos Móveis
Consumo de WebServices de todas as funcionalidades do Sistema.

É desnecessário dizer que usaremos o HTML5 e o CSS3 tanto no Java, que será implementado via primefaces e no MVC 4 utilizando.

Arquitetura para o PHP
A minha idéia é criar um página do zero utilizando o PHP, ou seja, vou fazê-lo todo orientado a objetos, diante disso, vai demorar um pouco mais até porque é necessário que eu faça uma reestudo sobre a nova versão do PHP e ver o que mudou com relação a versão anterior. Porém, estou com certa dúvida se utilizo ou não frameworks, o framework que eu utilizaria seria o cakePHP que é um framework MVC e de fácil compreensão e utilização.

- Camada de Apresentação: HTML5 + CSS3 + jQuery + jQueryUI
- Controle de Sessão e Camada de Segurança.

Os Rumos dos Artigos

Sei que muitos leitores estão querendo saber como que faremos os artigos subsequentes para que tornemos este Projeto uma realidade. Bem, eu posso atender a todos os gostos e como eu disse, este blog é bastante cosmopolita. Para aqueles que já tem um bom conhecimento e que não precisa conhecer os conceitos básicos das linguagens já iniciarei com o primeiro artigo do Sistema. Mas, caso o leitor não se sinta confortável com os códigos que está vendo e necessite de um apoio mais básico ou intermediário, então, também farei, em paralelo com os artigos do Sistema, artigos comentando o básico de todas as linguagens empregadas neste blog, é uma forma de ajudar a todos e que consigam andar e acompanhar o "ritmo".

Então, o primeiro artigo que faremos será a Modelagem do Sistema contendo a abstração principal, Formulários de Caso de Uso, Diagramas de Casos de Uso e etc. O primeiro artigo de codificação do Sistema será feito em Java e vamos utilizar o primeiro cenário: EJB. O que isso significa: que farei primeiramente um artigo sobre EJB para dar uma base ao leitor e logo em seguida, vamos fazer as codificações de dentro do Sistema. Não se preocupe em baixar os códigos, posto que em cada artigo informaremos o que deve ser baixado e como ser instalado. Já para os leitores que conhecem um pouco menos do Java, vamos começar com Orientação a Objetos baseado no Java, Orientação a Objetos baseado no C# e Orientação a objetos baseado no VB.NET.

Então, até o próximo artigo e lembre-se sempre de fortalecer o trabalho em equipe porque não se consegue nada e nenhuma vitória sozinho.

É um prazer tê-lo - ou tê-la - como leitor - ou leitora.

Forte Abraço a todos.

quarta-feira, 14 de agosto de 2013

Utilizando o padrão Java Bean \ POJO em suas Classes Java

Classe JavaBean


Uma Classe Java Bean é um  POJO significa Plain Old Java Object, ou seja, o bom e velho objeto escrito em Java puro, mais ou menos é este o significado.


Por que utilizar um Java Bean?


Tal Classe segue o padrão da Oracle para Classes Java e que pode ser utilizada como entidades e que são mundialmente aceitas e permitidas em qualquer projeto. Caso você, nobre e caríssimo leitor, chegar em uma entrevista ou mesmo em uma prova destas de RH, um processo seletivo, e criar tal classe de forma correta, pode ser que o emprego não seja seu, mas pelo menos você estará sendo visto com outros olhos pelo técnico que irá fazer a entrevista com você.


Como é estruturado um Java Bean?

Um Java Bean precisa ser Serializado. Em caso de transferência da Entidade em um ambiente de cliente/servidor, ele possa ser transferido e resgatado com facilidade sem problemas em suas threads, onde ele possa ser sincronizado.

Um Java Bean precisa conter atributos privados. Estas Classes precisam respeitar o encapsulamento protegendo seus atributos e se comunicando com o mundo exterior através de mensagens, ou seja, através de métodos de leitura e escrita nestes atributos, os chamados Getters/Setters.

Um Java Bean precisa conter um construtor vazio. Como padrão, tal Classe precisa de um construtor padrão criado para que seja criada. Esta é a forma mais primária para se inicializar tal classe, muitos frameworks, tais como Hibernate, nos obriga a ter pelo menos um construtor Default em nossa Entidade, se suas Classes sempre forem Java Beans, isso não será problema, por isso que devemos sempre utilizar este padrão.

Um Java Bean precisa conter um construtor com parâmetros. Para receber todos os valores dos atributos dentro do domínio da Classe, não é preciso colocar os relacionamentos, apenas os atributos padrão. Este construtor serve para que quando instanciamos a Classe já possamos passar todos os valores diretamente para ela sem a necessidade de usar os métodos para passar as mensagens.

Um Java Bean precisa conter métodos publicos Getters\Setters. Estes métodos servem de entrada\saída para acesso aos atributos pelas classes externas ao pacote.

Um Java Bean precisa sobrescrever o método ToString(). Este método deve imprimir o conteúdo do objeto, a forma correta é o método retornar todos os valores dos atributos, no modo padrão, quando o objeto é impresso, ele apenas mostra o caminho do objeto e não o seu conteúdo. Tal método é oriundo da Super Classe java.lang.Object.

Um Java Bean precisa sobrescrever o método HashCode(). Este método serve para controlar as instâncias em memória, com ela é possível verificar quais são e quando equals() é acionado, HashCode ajuda na diferenciação dos objetos. Tal método é oriundo da Super Classe java.lang.Object.

Um Java Bean precisa sobrescrever o método Equals(). Este método verifica se objetos são idênticos, o padrão é uma forma muito pobre de verificação e um tanto fraca, também é importante a sobrescrita deste método.

Um Java Bean precisa conter uma identificação única. Este atributo é opcional, mas ter um id é muito importante para controlar a ocorrência de tais entidades e objetos.

Tal método é oriundo da Super Classe java.lang.Object.
Abaixo, vemos na prática uma Classe JavaBean POJO.

package com.blogger.peripeciasdesenvolvedor.entidade;

import java.io.Serializable;

public class JavaBeanPadrao implements Serializable{

private static final long serialVersionUID = 8982198782797245834L;

 //Atributos 
 private Integer id;
 private String nome;
 private String sobrenome;
 private String email;
  
 //Construtor Padrão
 public JavaBeanPadrao() {
  
 }

 //Construtor com Parâmetros
 public JavaBeanPadrao(Integer id, String nome, String sobrenome,
   String email) {
  super();
  this.id = id;
  this.nome = nome;
  this.sobrenome = sobrenome;
  this.email = email;
 }

 //Getters e Setters
 public Integer getId() {
  return id;
 }

 public void setId(Integer id) {
  this.id = id;
 }

 public String getNome() {
  return nome;
 }

 public void setNome(String nome) {
  this.nome = nome;
 }

 public String getSobrenome() {
  return sobrenome;
 }

 public void setSobrenome(String sobrenome) {
  this.sobrenome = sobrenome;
 }

 public String getEmail() {
  return email;
 }

 public void setEmail(String email) {
  this.email = email;
 }
 
 //Sobrescritas de java.lang.Object
 @Override
 public boolean equals(Object obj) {
  
  if (obj instanceof JavaBeanPadrao){
   JavaBeanPadrao pojo = (JavaBeanPadrao) obj;
   
   if (pojo.id != null && this.id != null){
    return pojo.getId().equals(id);
   }
  }
  
  return false;
 }

 @Override
 public int hashCode() {
  
  return this.id != null ? this.id.hashCode():0;
 }

 @Override
 public String toString() {
  
  return this.id + ", " + this.nome + ", " + this.sobrenome + ", " + this.email;
 }

}

Vamos agora para a implementação deste nosso Java Bean.
O exemplo abaixo,ilustra o uso do construtor padrão, setters e impressão com ToString().

package com.blogger.peripeciasdesenvolvedor.principal;

import com.blogger.peripeciasdesenvolvedor.entidade.JavaBeanPadrao;

public class Principal {

 public static void main(String[] args) {
  
  //Instancia do POJO construtor padrão
  JavaBeanPadrao pojo = new JavaBeanPadrao();
  
  //Populando os atributos através do encapsulamento
  pojo.setId(1);
  pojo.setNome("Gabriel");
  pojo.setSobrenome("Simas");
  pojo.setEmail("gabrielsimas@gmail.com");
  
  //Imprimindo via ToString()
  System.out.println(pojo);
  
 }

}

A saída do exemplo acima é:

1, Gabriel, Simas, gabrielsimas@gmail.com
Como podemos notar no código anterior, a saída e justamente o nosso método ToString() modificado corretamente, veja que existe uma diferença, posto que o resultado está totalmente transparente e também demonstra como o nosso setter é eficiente de forma que passou os valores para os atributos corretamente, sem a necessidade de acessá-los diretamente. O próximo trecho de código ilustra o uso do construtor com parâmetros e sua posterior Impressão.
package com.blogger.peripeciasdesenvolvedor.principal;

import com.blogger.peripeciasdesenvolvedor.entidade.JavaBeanPadrao;

public class Principal {

 public static void main(String[] args) {
  
  //Instancia do POJO com construtor com parametros
  JavaBeanPadrao pojo = new JavaBeanPadrao(1, "Gabriel", "Simas", "gabrielsimas@gmail.com");
  
  //Imprimindo via ToString()
  System.out.println(pojo);
  
 }

}

O resultado deste código será
1, Gabriel, Simas, gabrielsimas@gmail.com
O resultado é o mesmo, sendo que escrevemos bem menos para atingir o mesmo resultado, este tipo de modificação se chama refatoração ou refactoring, onde executamo as mesmas tarefas de forma otimizada.
Neste artigo vimos como se constrói um Java Bean simples e funcional, o que nos dará uma boa base para os próximos artigos, lembre-se que neste Blog, a informação é sempre sequencial, ou seja, um artigo complementa o artigo anterior de forma a sempre utilizar o que já fora mostrado aqui. Lembre-se sempre de fortalecer o trabalho em equipe, afinal de contas, não se vence sozinho. Forte Abraço, muito obrigado por sua visita e até a próxima.

O que serão as peripécias

Neste primeiro post do Blog, não vou falar sobre códigos, nem de bits e muito menos de bytes. Vou apenas falar um pouco da minha experiência de programador e como eu comecei neste ramo que até hoje me deixa muito feliz.

Tudo começou no ano de 1996, no mês de Outubro, eu tinha 14 anos naquela época e já tinha estudado um pouco sobre Eletrônica e estava disposto a cair dentro dos Circuitos Integrados já bastante empolgado, estava querendo entrar na Escola Técnica Rezende-Hamel... não me lembro se o Hamel é com "H", pois bem... meu pai tinha uma coleção do Jornal O Globo do final da década de 80 do século XX, se chamava Curso Globo de Microinformática, nele eu vi fotos do Bill Gates nem novo dizendo que a "Microsoft ainda seria uma grande empresa" dada a antiguidade da coleção.
Dentro dela, aprendi sobre algoritmos, estruturas de dados e sobre a Análise Estruturada moderna, o que hoje em dia se ensina em todas as universidades e a linguagem era o BASIC, porém, o BASIC na década de 80 era utilizado por cada fabricante a seu bel prazer, por exemplo, a Apple detinha um BASIC que ser magnífico para a criação de jogos... pois tinha uma função chamada "scroll" que fazia o trabalho de colocar os bits em uma nova linha em uma matriz e fazia um efeito de se movimentar pela tela como os jogos do tipo Scroll hoje em dia. Bem, eu comecei a usar o chinês e a fazer programar e algoritmos em uma folha de papel, na época eu estudava no CEMADE - Complexo Educacional Avenida dos Desfiles, era uma escola municipal que funcionava dentro da Passarela do Samba, aqui no Rio de Janeiro, uma Cidade Maravilhosa. Confesso que era um bom aluno e lá já detinha alguns amores de adolescente, alguns correspondidos outros não, mas que não sinto saudades daquela época, a única saudade mesmo é que eu apenas estudava: como eu era feliz e não sabia!
Diante deste cenário, meu pai, que não tinha muitas posses comprou um IBM 486 DX2 comprado na Loja Garson, atualmente seria uma Insinuante ou Ricardo Eletro se fôssemos seguir de fusão em fusão.
A priori eu vi naquela máquina algo inusitado, vi que o teclado começava com QWERTY e não com ABCDE... achei-o totalmente complicado.
A Plataforma era o Windows 3.11 for Workgroups e logo em um mês já o estava dominando graças ao Manual do Windows que antigamente era do peso e tamanho de uma Bíblia e muito bem escrito... hoje em dia algo do gênero só comprando livros do Minasi.
Aprendi a usar o mouse, no início foi meio estranho, mas depois passei a me acostumar com o dispositivo e fí-lo uma extensão de minha mão.
Encontrei o QBASIC dentro do Windows, o QBASIC tinha muitas limitações, mas dava para criar os programas que eu tinha escrito em papel e fazer funcionar tudo o que eu precisava, principalmente o meu primeiro programinha: um solucionador de Equações de primeiro grau e segundo grau... A programação, principalmente o BASIC, começou a me ajudar e fazer com que o PC agregasse valor na minha vida e eu iniciava a minha vida profissionall. Após isso, estava ávido por um Windows 95 e como todo adolescente eu tinha vontade de jogar. Eu comprava, naquela época, a Revista do CD-ROM que hoje se chama WWW.COM.BR se não me falha a memória e lá tinham jogos que rodavam sempre em MS-DOS 6.22 e era justamente o Sistema Operacional existente na minha máquina. E me lembro de que também veio um Guia do Usuário do MS-DOS 6.22 e este guia ia do básico ao avançado e eu comecei a aprender a controlar a memória RAM via autoexec.bat e config.sys para que eu pudesse melhorar a memória usei a memória EMS... colocava buffers e por aí eu ia e conseguia rodar jogos como Top Gun: Fire at Will e Quake I dentro da máquina, ficavam meio lentos, mas eu conseguia jogá-los e com isso comecei a me interessar em aprender o que fazia tudo aquilo funcionar.
Hoje em dia eu crio Sistemas Profissionais Web utilizando .NET com C# e Java EE e colocarei aqui neste Blog a minha próxima aventura que é aprender e dominar a programar em VB.NET posto que estou precisando levantar alguns projetos neste CLR. Não vou deixar de publicar artigos em C# e Java.

Espero que gostem dele.

Forte Abraço a todos.