Investigacao da efetividade de um framework corporativo de ... da Silva Avansini... · VBA –...
58
Universidade Estadual de Maringá Centro de Tecnologia – Departamento de Informática Especialização em Desenvolvimento de Sistemas para Web Investigação da efetividade de um Framework Corporativo de persistência de dados com base no Framework NHibernate em um ambiente empresarial. Régis da Silva Avansini Prof. Dr. Edson A. Oliveira Junior Orientador Maringá, 2012
Transcript of Investigacao da efetividade de um framework corporativo de ... da Silva Avansini... · VBA –...
Universidade Estadual de Maringá Centro de Tecnologia – Departamento de Informática
Especialização em Desenvolvimento de Sistemas para Web
Investigação da efetividade de um Framework Corporativo de
persistência de dados com base no Framework NHibernate em um
ambiente empresarial.
Régis da Silva Avansini
Prof. Dr. Edson A. Oliveira Junior Orientador
Maringá, 2012
Universidade Estadual de Maringá Centro de Tecnologia – Departamento de Informática
Especialização em Desenvolvimento de Sistemas para Web
Régis da Silva Avansini
Investigação da efetividade de um Framework Corporativo de
persistência de dados com base no Framework NHibernate em um
ambiente empresarial.
Trabalho submetido à Universidade Estadual de
Maringá como requisito para obtenção do título
de Especialista em Desenvolvimento de Sistemas
para Web.
Orientador: Prof. Dr. Edson A. Oliveira Junior
Maringá, 2012
Investigação da efetividade de um
Framework Corporativo de persistência de
dados com base no Framework NHibernate
em um ambiente empresarial.
PARECER DA BANCA EXAMINADORA
RÉGIS DA SILVA AVANSINI
DATA DA DEFESA: _____/_____/_____
Trabalho apresentado nesta data ao Curso de Especialização em Desenvolvimento de
Sistemas para Web da Universidade Estadual de Maringá, examinado pela Banca
Examinadora composta pelos professores:
_______________________________________
Prof. Dr. Edson A. Oliveira Junior (Orientador)
______________________________________
Prof. Dr. Tania Fatima Calvi Tait (Professor Convidado)
______________________________________
Prof. Dr. Renato Balancieri (Professor Convidado)
PARECER CONCLUSIVO:
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________
______________________________________________________________
DEDICATÓRIA
“Dedico este trabalho aos meus familiares, amigos e usuários do Framework NHibernate”.
AGRADECIMENTOS
“Agradeço a todos os profissionais que me auxiliaram com opiniões distintas sobre as
ferramentas comparadas nesta pesquisa e aos amigos de turma da ESPWEB”.
Avansini, Régis Silva. Investigação da efetividade de um Framework Corporativo de
persistência de dados com base no Framework NHibernate em um ambiente empresarial.
2012. Monografia (Especialização em Desenvolvimento de Sistemas para Web), Universidade
Estadual de Maringá.
RESUMO
O aumento da demanda por soluções de software junto com o pouco prazo de entrega
estabelecido pelos seus clientes faz com que as empresas da área de desenvolvimento de
softwares busquem soluções para assegurar a entrega de seus produtos garantindo ainda a
qualidade do produto final, por isso muitas optam por criarem frameworks corporativos para
reutilização de seus próprios códigos fonte. Alguns desses frameworks são concebidos para
funções específicas como mapear os objetos de sua aplicação para o modelo entidade
relacionamento do banco de dados, contudo já existem soluções disponíveis e gratuitas para
realização dessa funcionalidade. Este trabalho visa levantar as principais informações de dois
frameworks de persistência de dados, identificando desempenho, manutenção, escalabilidade,
curva de aprendizado e opiniões de analistas e programadores para que seja possível comparar
qual deve ser adotado em determinados cenários de desenvolvimento. Para realização dos
estudos foram escolhidos o NHibernate e o framework corporativo desenvolvido por uma
empresa privada, identificando assim o NHibernate como o mais efetivo com base nas
comparações realizadas.
Palavras-Chave: Framework, C#, NHibernate, Persistência, Mapeamento Objeto-Relacional,
Corporativo.
Avansini, Régis Silva. Investigação da Efetividade de um Framework Corporativo de
Persistência de Dados com Base no Framework NHibernate em um Ambiente
Empresarial. 2012. Monografia (Especialização em Desenvolvimento de Sistemas para
Web), Universidade Estadual de Maringá.
ABSTRACT
The increased demand for software solutions along with the little lead time provided by its
customers makes the companies in the area of software development to seek solutions to
ensure the delivery of its products while ensuring the quality of the final product, so many
choose to create frameworks for corporate reuse their own source code. Some of these
frameworks are designed for specific functions such as mapping the objects of your
application to the entity relationship model of the database, however there are solutions
already available for free to achieve this functionality. This work aims to raise the key
information from two data persistence frameworks, identifying performance, maintainability,
scalability, learning curve and opinions of analysts and programmers to be able to compare
which should be adopted in certain deployment scenarios. For the studies were chosen
NHibernate and corporate framework developed by a private company, thus identifying
NHibernate as the most effective based on comparisons made.
Keywords: Framework, C #, NHibernate, Persistence, Object-Relational Mapping,
Corporate.
LISTA DE ABREVIATURAS E SIGLAS
ADO – ActiveX Data Objects.
API – Application Programming Interface.
CLR – Common Language Runtime.
CRUD – Create, Read, Update and Delete.
CSLA – Component-based, Scalable, Logical Architecture.
DBA – Data Base Administrator.
DB2 – Banco de Dados IBM.
DLL – Dynamics Link Library.
DTO – Data Transfer Object.
GNU – General Public License.
IIS – Internet Information Services.
LGPL – Lesser GNU Public License.
LOG – Registro de erros e monitoramento.
MVC – Model-View-Controller.
OO – Orientação a Objetos.
POCO – Plain Old CLR Object.
SGBD – Sistema Gerenciador de Banco de Dados.
SQL – Structure Query Language.
TI – Tecnologia de Informação
URL – Uniform Resource Locator.
VBA – Visual Basic.
XML – Extensible Markup Language.
SUMÁRIO
1. INTRODUÇÃO ..................................................................................................... 1
2. PADRÕES DE PROJETOS E ARQUITETURA DE SOFTWARE ....................... 3
3. FRAMEWORKS ................................................................................................. 10
3.1 Classificação de frameworks ................................................................................ 11
3.2 Tipos de frameworks ............................................................................................. 12
3.3 Vantagens e desvantagens ................................................................................... 13
4. FRAMEWORK CORPORATIVO ....................................................................... 14
4.1 Arquitetura do framework corporativo ................................................................ 14
4.2 Características do framework corporativo .......................................................... 16
4.3 Processo de criação e utilização do framework corporativo ........................... 16
4.4 Configuração do framework corporativo ............................................................ 17
4.5 Mapeamento objeto-relacional ............................................................................. 18
5. FRAMEWORK NHIBERNATE ........................................................................... 23
5.1 Arquitetura do NHibernate .................................................................................... 23
5.2 Principais características do NHibernate ............................................................ 25
5.3 Processo de criação e utilização do NHibernate ................................................ 26 5.3.1 Abordagem bottom-up ............................................................................................................... 27 5.3.2 Abordagem top-down ................................................................................................................. 28
5.4 Configuração do NHibernate ................................................................................ 28
5.5 Mapeamento objeto-relacional ............................................................................. 30 5.5.1 Mapeamento de tabelas-classes .............................................................................................. 34 5.5.2 Mapeamento de chave primária ............................................................................................... 34 5.5.3 Mapeamento muitos-para-um ................................................................................................... 35 5.5.4 Mapeamento Um-para-Um ........................................................................................................ 35
6. COMPARAÇÃO DOS FRAMEWORKS ............................................................. 37
7. CONCLUSÃO E TRABALHOS FUTUROS ....................................................... 43
REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................... 46
APÊNDICE A – QUESTIONÁRIO FRAMEWORKS ................................................. 47
LISTA DE FIGURAS
Figura 2.1 – Diagrama de classes para o padrão Factory Method (Fonte: Autor) ............ 4
Figura 2.2 – Diagrama de classes para o padrão Adapter (Fonte: Autor) ........................ 5
Figura 2.3 – Diagrama de classes para o padrão Observer (Fonte: Autor) ...................... 6
Figura 2.4 – Diferentes representações para um mesmo modelo (fonte: [3]) ................... 8
Figura 2.5 – Modelo de arquitetura de software em camadas MVC (fonte: Autor) ......... 9
Figura 3.1 – Representação do modelo vertical de frameworks (fonte: [6]) ................... 11
Figura 3.2 – Representação do modelo horizontal de frameworks (fonte: [6]) ............... 12
Figura 3.3 – Representação dos tipos de frameworks (fonte: autor) ............................. 13
Figura 4.1 – Camadas básicas de um aplicativo (fonte: [7]) ......................................... 15
Figura 4.2 - Arquitetura do framework corporativo (fonte: [7]) ................................... 15
Figura 4.3 – Arquitetura das classes e entidades do framework (fonte: [7]) ................... 18
Figura 4.4 – Exemplo de entidade do banco de dados a ser mapeado (fonte: [7]) .......... 19
Figura 4.5 – Objeto POCO instanciado da entidade ACTIVITY (fonte: [7]) ................ 19
Figura 4.6 – Objeto serializado da entidade ACTIVITY (fonte: [7]) ............................ 20
Figura 4.7 – Classe POCO da entidade ACTIVITY (fonte: [7]) ................................... 21
Figura 5.1 – Visão de alto nível da arquitetura do framework NHibernate (fonte: [9]) ... 23
Figura 5.2 – Visão da arquitetura do framework NHibernate (fonte: [9]) ...................... 24
Figura 5.3 – Visão detalhada da arquitetura do framework NHibernate (fonte: [9]) ...... 24
Figura 5.4 – Utilização botton-up do NHibernate (fonte: autor) .................................... 27
Figura 5.5 – Utilização top-down do NHibernate (fonte: autor) ..................................... 28
Figura 5.6 – Configuração do NHibernate dentro do web.config (fonte: [10])................ 29
Figura 5.7 – Mapeamento XML da entidade cliente (fonte: autor) ............................... 32
Figura 5.8 – Classe POCO para mapeamento da Figura 6.7 (fonte: autor) ................... 32
Figura 5.9 – Classe POCO mapeada da entidade cliente (fonte: autor) ........................ 33
Figura 5.10 - Classe POCO para mapeamento fluente da entidade cliente (fonte: autor)
.................................................................................................................................. 33
Figura 5.11 – Classe de mapeamento para entidade cliente (fonte: autor) .................... 33
Figura 5.12 – Atributos e valores, mapeamento muito-para-um XML (fonte: [10]) ...... 35
Figura 5.13 – Mapeamento um-para-um em arquivo XML (fonte: [10]) ...................... 36
Figura 5.14 – Atributos e valores, mapeamento um-para-um XML (fonte: [10]) .......... 36
Figura 6.1 – Tempo de adaptação do usuário do NHibernate (fonte: autor) .................. 38
Figura 6.2 – Tempo de adaptação do usuário do framework corporativo (fonte: autor) 39
LISTA DE TABELAS
Tabela 5.1 – Configuração de banco de dados para o NHibernate (fonte: autor) ........... 30
Tabela 5.2 – Estrutura da entidade cliente (fonte: autor) ............................................. 31
Tabela 6.1 – Comparação das ações de mapeamento dos frameworks (fonte: autor) ..... 40
Tabela 6.2 – SGBD’s suportador por ambos frameworks ............................................ 41
1
1. INTRODUÇÃO
Na última década o desenvolvimento de novos aplicativos de software teve um
aumento significativo, fazendo com que empresas da área de desenvolvimento de software
adotassem metodologias e técnicas para aperfeiçoar o ciclo de vida dos seus produtos. Um dos
principais desafios de empresas fornecedoras deste tipo de serviço é atender a demanda de
customização de seus produtos no menor período de tempo possível. Contudo, faz-se
necessário que tais empresas desenvolvam soluções que possam reutilizar os seus próprios
códigos fonte, componentes e interfaces em novos projetos. Para tanto, tais empresas adotam
o uso de frameworks próprios (corporativos), optando em despender recursos humanos e
tecnológicos nos estágios iniciais de seus projetos para concebê-los atendendo às suas
necessidades.
Entretanto, tomar a decisão de optar por uma ferramenta corporativa ou adotar um ou
vários frameworks comerciais pode não ser uma tarefa trivial. O uso de tecnologia própria
pode parecer uma boa estratégia quando usada de forma correta, caso contrário pode acarretar
em alto custo de tempo e recurso, o que pode reduzir o retorno de investimento da empresa.
Vários aspectos devem ser levados em consideração antes de decidir qual framework
adotar, entre eles pode-se destacar: a escalabilidade do framework, o tempo de adaptação da
equipe de usuários, o desempenho, o tempo de concepção de novos produtos, a adaptação do
aplicativo, o conhecimento compartilhado entre a comunidade de software, a difícil
manutenção, o código morto e a falta de capacitação dos profissionais.
Outro caminho no processo de reutilização de recursos é adotar frameworks de
mercado, desenvolvidos por terceiros. Atualmente, são vários os tipos de frameworks
encontrados, alguns com características bem definidas como, por exemplo, persistência de
dados.
Este trabalho tem como objetivo apresentar um estudo comparativo entre dois
frameworks, atualmente adotados por uma empresa com o intuito de identificar qual é o mais
efetivo. O primeiro framework foi desenvolvido pela própria empresa. Ele abrange todas as
camadas de desenvolvimento de uma nova aplicação, contudo neste trabalho é considerada
apenas a persistência de dados. O segundo framework é NHibernate. Tal framework foi criado
estritamente para realizar a persistência de dados.
2
Para a realização deste trabalho foi necessário levantar informações sobre padrões de
projetos de software e arquitetura de software para identificar as necessidades de uma camada
de persistência de dados, em seguida foram estudados os modelos de frameworks existentes
para identificar em quais se encaixam os frameworks aqui comparados, após isso foram
estudados as principais características e arquitetura de ambos os frameworks. Além disso, foi
considerada a experiência de profissionais que tenham trabalhado com uma ou ambas as
ferramentas, por meio de aplicação de um questionário.
Este trabalho está estruturado da seguinte maneira: o capítulo 2 apresenta os principais
conceitos sobre padrões de projeto, amplamente conhecidos como Design Patterns e
conceitos referentes à organização de aplicações em camadas, especificamente na camada de
persistência de dados, tomando como referência o padrão de arquitetura de software MVC
(Model – View - Controller); o capítulo 3 possui uma definição dos tipos de frameworks
encontrados; o capítulo 4 contempla as informações essenciais pertinentes ao framework
corporativo; o capítulo 5 engloba o framework NHibernate; o capítulo 6 apresenta os
resultados obtidos e a comparação realizada entre ambos os frameworks; e o Capítulo 7
apresenta as conclusões e direções para trabalhos futuros. No apêndice A está o questionário
aplicado junto aos profissionais da área.
3
2. PADRÕES DE PROJETOS E ARQUITETURA DE SOFTWARE
Independente da linguagem de programação utilizada, ou da empresa ou ainda da
aplicação que esteja sendo criada, a manutenção está presente. Com o tempo o software irá
crescer e mudar para não se tornar obsoleto. Por exemplo, a alteração do SGBD (Sistema
Gerenciador de Banco de Dados), nem sempre é possível, pois ele está diretamente
relacionado com a forma em que a aplicação foi construída [2], ou seja, um padrão está
diretamente relacionado com a abstração dos detalhes encontrados na criação de um novo
aplicativo de software [3].
Os padrões de projetos de software ou Design Patterns fornecem uma estrutura de
projeto OO (Orientado a Objetos) capaz de solucionar problemas comuns ao processo de
desenvolvimento, visando reutilizar as soluções já encontradas e melhorar a manutenção [2].
Segundo Christopher Alexander [1], “Cada padrão descreve um problema que ocorre
repetidas vezes em nosso ambiente e o núcleo da solução para tal problema, de tal forma que
possamos usar essa solução de diferentes formas sem nunca fazê-la da mesma maneira duas
vezes”.
Os padrões de projetos estão entre os mais importantes avanços da engenharia de
software nos anos de 1990, uma simples abstração do que é flexível dentro de uma aplicação,
e/ou seu remanejamento dentro do projeto para que possa sofrer alterações no decorrer do
processo de forma organizada já se caracteriza como um padrão de projeto de software. O
padrão comportamental Strategy, por exemplo, define um conjunto de classes, encapsula cada
uma delas e as torna intercambiáveis.
Alguns cuidados devem ser levados em consideração na utilização de padrões de
projetos. Deve-se evitar tornar flexível o que não precisa ser flexível. Muitas partes do código
escrito não se relacionam com o problema que será resolvido, o número de classes tende a
aumentar e o relacionamento entre elas ficará mais complexo [3].
Os padrões de projetos são organizados em três grandes categorias, que são: padrões
de criação, padrões estruturais e padrões comportamentais [3].
Os padrões de criação dizem respeito a como se instanciar objetos. Gamma [3] define
cinco padrões de criação: Factory Method, Abstract Factory, Builder, Prototype e Singleton.
4
Esses padrões têm como objetivo ajudar o sistema a tornar-se independente da forma como os
objetos são criados, encapsulando o conhecimento sobre quais classes o sistema faz uso [3].
O padrão Factory Method, por exemplo, fornece uma interface para criar grupos de
objetos que se relacionam sem especificar suas classes concretas. Para isso, é definida uma
interface para criar um objeto, deixando a responsabilidade de quais classes instanciar para as
classes menos ancestrais. A Figura 2.1 apresenta um diagrama de classes para o padrão
Factory Method.
Figura 2.1 – Diagrama de classes para o padrão Factory Method (Fonte: Autor)
Pode-se observar na Figura 2.1 que é um padrão de projeto que visa encapsular a
criação de um objeto em um método [3] reduzindo o acoplamento da aplicação, portanto é um
padrão de projeto que pode e deve ser utilizado em conjunto com outros padrões de criação,
comportamentais ou estruturais.
Os padrões estruturais correspondem à forma com que as classes e objetos se associam
para construir estruturas ainda maiores e descrevem a forma em que os objetos são compostos
para se obter novas funcionalidades. São sete os padrões estruturais definidos por Gamma
[3]: Adapter, Bridge, Decorator, Proxy, Façade, Composite, Flyweight.
O padrão Adapter, também conhecido como Wrapper tem como objetivo adaptar o
uso de uma interface. Sua função é auxiliar no casting de uma interface de uma classe para
outra interface que contenha um comportamento mais apropriado para atender a um requisito
especifico [3]. Esse padrão nos permite reescrever alguns requisitos ou métodos pertencentes
5
à uma classe adaptada tornando a aplicação mais versátil. Além disso, não se faz necessário
utilizar outros objetos para se obter o tipo da classe desejada. A Figura 2.2 apresenta um
diagrama de classes para o padrão Adapter.
Figura 2.2 – Diagrama de classes para o padrão Adapter (Fonte: Autor)
Para utilizar um padrão estrutural como o Adapter é necessária a utilização de um
padrão de criação. O diagrama de classes da Figura 2.2 é uma evolução do padrão Factory
Method representado pela Figura 2.1 fazendo uso do Adapter.
Padrões comportamentais definem como os elementos interagem entre si além do
comportamento de cada um na aplicação, classes e objetos. Eles lidam com algoritmos e a
distribuição de responsabilidade entre as classes e objetos, descrevendo um padrão de
comunicação entre os objetos relacionados. Os padrões comportamentais descritos por
Gamma [3] são: Chain of Responsability, Command, Interpreter, Iterator, Mediator,
Memento, Observer, State, Strategy, Template Method e Visitor.
O padrão Observer, define uma relação de dependência um para muitos entre os
objetos que se relacionam, assim quando um objeto muda de estado todos os seus dependentes
serão notificados e atualizados também [3]. Esse padrão é facilmente identificado na camada
6
de controle do modelo de arquitetura em camadas de software MVC. A Figura 2.3 apresenta o
diagrama de classes para o padrão Observer.
Figura 2.3 – Diagrama de classes para o padrão Observer (Fonte: Autor)
Essas notificações demonstradas na Figura 2.3 poderiam ser feitas de forma manual,
contudo deixaria a aplicação com alto acoplamento e de difícil manutenção. Com a utilização
do Observer é possível reduzir o uso do relacionamento bidirecional entre as classes abstratas
e interfaces, obtendo baixo acoplamento e alta coesão.
Através do uso dos padrões vistos acima pode-se construir uma arquitetura mais
complexa, a arquitetura de software tem como objetivo estudar o sistema, analisando seus
componentes, as propriedades externamente visíveis e a forma como eles se relacionam de
acordo com sua natureza [4]. Um componente de um aplicativo de software nada, mas é do
que a abstração das classes, objetos, processos, rotinas, bibliotecas, base de dados e quaisquer
outras informações pertinentes ao que irá compor o software [4].
Na arquitetura de software devemos de certa maneira encapsular informações desses
componentes quando essas não forem relevantes para determinar como eles irão interagir.
Detalhes privados aos componentes não fazem parte da arquitetura em si [4].
7
Para arquitetar um software de maneira correta devemos considerar um maior escopo
de requisitos que compõem a aplicação, como por exemplo: confiabilidade, escalabilidade,
manutenção, segurança, custo de produção do produto além de tempo de vida do software.
Assim, a arquitetura deve representar a aplicação como um todo [4].
Padrões de arquitetura de software mais complexos como MVC, por exemplo, têm
como objetivo principal definir uma arquitetura para que os componentes de um aplicativo se
comuniquem entre si. Para isso, esse padrão define três camadas básicas para organizar seus
componentes, são elas: Modelo, visão e controlador, fazendo com que eles fiquem menos
acoplados, facilitando nas futuras alterações que a aplicação possa vir a sofrer [3].
A camada modelo é onde se encontram os principais requisitos da aplicação, ou seja, é
responsável por tudo que a aplicação irá realizar, se preocupando com a manipulação,
armazenamento e geração dos dados, de certa forma é um encapsulamento das informações e
comportamento independente de como será apresentado na camada de visão, contém toda a
regra de negócio a ser aplicada antes de realizar o mapeamento para persistir os dados.
A camada de visão não se relaciona diretamente com a camada modelo. Não importa
como os dados foram obtidos e nem de que forma foram ou muito menos de onde eles vêm.
Essa camada se preocupa apenas em exibir a informação para o usuário, na camada de visão
encontra-se o front-end da aplicação variando de acordo com a aplicação, ou seja, telas
desenvolvidas em Forms, Silverlight, páginas html, etc.
A camada de controle é responsável em determinar o fluxo da apresentação dos dados.
Ela funciona como uma camada intermediária entre a camada modelo e visão, controla e
mapeia as ações entre ambas. Nesta camada encontram-se classes responsáveis em transferir
os objetos entre as camadas, são as chamadas classes DTO (Data Transfer Object).
O MVC garante o baixo acoplamento entre as camadas, fazendo uso dos padrões de
projeto definido por Gamma [3]. A Figura 2.4 demonstra um elemento da camada modelo
sendo representado por três elementos distintos da camada visão.
8
Figura 2.4 – Diferentes representações para um mesmo modelo (fonte: [3])
O objetivo do MVC é aumentar a flexibilidade e a reutilização da aplicação, a camada
de visão deve garantir que reflita a situação atual da camada modelo, ou seja, do objeto que
representa. Assim, sempre que esse objeto sofrer alguma alteração ele irá notificar todas as
interfaces da camada de visão que dependem dele [3].
O MVC é aplicável a uma arquitetura maior. Ele deve ser capaz de desassociar os
objetos da camada de visão para que mudanças para uma determinada visão não afetem outra.
Isso pode ser obtido ao utilizar o padrão de projeto Observer. Outro aspecto do MVC é que se
podem ter pontos de vista idênticos para determinadas classes da camada de visão.
Comportamentos idênticos que podem ser reutilizados, por exemplo, conjunto de controle de
ações de um formulário pode ser único para vários formulários. Para isso, faz-se uso do
padrão de projeto Composite.
Uma visão usa uma instância de uma subclasse controladora para programar uma
estratégia de resposta particular. Se desejar programar uma estratégia diferente basta substituir
a instância com um tipo diferente de controlador. É ainda possível alterar o controlador de
uma visão em tempo de execução para permitir à visão mudar a maneira como ele responde à
entrada de ações do usuário. Tal relação entre a camada de visão e a camada controladora é
um exemplo do padrão de projeto Strategy. O MVC ainda utiliza os padrões de projeto
Factory Method e Decorator para especificar uma classe controladora padrão e para adicionar
atributos para a visão respectivamente, mas as principais relações da arquitetura MVC são os
padrões de projeto Observer, Composite e Strategy [3].
As principais do MVC é que ele permite: aumentar o número de clientes que
consomem os recursos da camada de modelo adicionando apenas novas visões e
controladores, tornar a aplicação escalável e facilitar a manutenção e testes, além de permitir
9
o desenvolvimento em paralelo das camadas que compõem o aplicativo [3]. As principais
desvantagens desse modelo é que ele necessita de um maior tempo para analisar e modelar o
sistema como um todo. Além disso, requer recursos humanos especializados, não sendo
aconselhado para aplicações de pequeno porte [3].
Atualmente, existem algumas variações do MVC, devido à influência de novas
tecnologias e também devido as necessidades que surgem no desenvolvimento de algumas
aplicações. Mas, tradicionalmente esse modelo possui o relacionamento e comportamento
entre as camadas como mostrado na Figura 2.5 [3].
Figura 2.5 – Modelo de arquitetura de software em camadas MVC (fonte: Autor)
10
3. FRAMEWORKS
O uso desse conceito surgiu há alguns anos e vem agregando adeptos com o passar do
tempo. Com isso, o uso de frameworks tem se tornado cada vez mais comum no ambiente de
desenvolvimento.
Os frameworks não se relacionam a um domínio ou problema específico de uma
determinada aplicação. O seu objetivo é compor um conjunto de funções interdependentes
que visam representar uma solução parcial para um determinado problema. Portando, ele deve
servir de ponto de partida para criar a aplicação, a estrutura de classes, interfaces e objetos
que o compõem devem ser utilizadas (estendidas, implementadas e instanciadas) de acordo
com o problema especifico [5].
Entre as principais vantagens na utilização de frameworks, podemos citar: ganho na
produtividade, diminuição de erros no aplicativo, tempo de desenvolvimento da aplicação
reduzido além de tornar a aplicação mais homogênea.
A arquitetura de um framework por mais simples que seja tem relação com padrões de
projeto de software. São conceitos bem interligados, contudo não são obrigatoriamente
dependentes.
O objetivo de um framework é separar as partes da aplicação que podem sofrer
alteração das que permaneceram estáticas [5]. As classes não sofrem alterações,
independentemente das aplicações que estejam utilizando o framework, podendo apenas ter
suas classes estendidas.
São várias as áreas relacionadas à tecnologia que utilizam de frameworks. Nos dias de
hoje é possível encontrar frameworks próprios para interface gráfica, incorporação de
arquitetura de software como MVC, construção de scripts, mapeamento objeto-relacional
entre outros.
Normalmente frameworks são criados para atender um determinado conjunto de
problemas, sendo assim empresas da área de tecnologia tendem a criar frameworks
corporativos ao identificar uma mesma solução para problemas que tendem a surgir durante a
construção de suas aplicações. Durante o ciclo de vida dos softwares desenvolvidos é notada a
presença de classes comuns em diferentes projetos, e um conjunto dessas classes tende a ser o
ponto inicial da criação de um framework.
11
De certa forma um framework deve ser algo reutilizável e estável. Contudo, para que
seja utilizado de forma correta deve possuir a documentação apropriada para entendimento de
seu funcionamento e utilização. Basicamente, um framework deve em sua documentação
mostrar a razão para a existência de determinada funcionalidade, deve descrever como utilizar
seus recursos além de detalhar o comportamento das classes e objetos relacionados a um
determinado recurso.
3.1 Classificação de frameworks
Os frameworks podem ser classificados de acordo com o ambiente em que será
utilizado, por exemplo, um framework pode ser utilizado em nível de domínio, aplicação ou
suporte [6].
Os frameworks de domínio também conhecidos como frameworks verticais
encapsulam conhecimento que estejam relacionados a um determinado domínio. Eles tendem
a solucionar boa parte da aplicação de acordo com o conhecimento agregado [6]. A Figura 3.1
apresenta o modelo de crescimento vertical de um framework.
Figura 3.1 – Representação do modelo vertical de frameworks (fonte: [6])
12
Os frameworks de aplicação são o oposto dos frameworks de domínio. O
conhecimento agregado é relacionado a vários domínios diferentes. Esse tipo de framework
também é conhecido como framework horizontal, pois resolve apenas parte da aplicação. A
Figura 3.2 apresenta o modelo de crescimento horizontal de um framework.
Figura 3.2 – Representação do modelo horizontal de frameworks (fonte: [6])
Por fim, temos os frameworks de suporte, pouco utilizados, pois fornecem serviços
relacionados ao sistema e não à aplicação.
3.2 Tipos de frameworks
Os frameworks podem ser correlacionados em três tipos de acordo como foram
concebidos, são eles: frameworks White-box (caixa branca), Black-box (caixa preta) e Gray-
box também conhecidos como híbridos [6].
Os frameworks caixa-branca fornecem classes abstratas que deverão ser especializadas
de acordo com a necessidade da aplicação. Assim, os desenvolvedores de sistema estendem o
framework utilizando o recurso de herança presente na OO, por exemplo, a classe Object da
linguagem de programação C#.
13
Os frameworks caixa-preta fornecem classes já utilizáveis em que os programadores
devem instanciar essas classes diretamente para utilizar os objetos que compõem o
framework, por exemplo, Swing (GUI) da linguagem de programação Java.
Por fim, tem-se os frameworks híbridos que agregam características dos frameworks
caixa-branca e caixa-preta. A grande maioria dos frameworks presentes no mercado se
enquadra nesse tipo, tanto os frameworks Open-Source como os frameworks corporativos. A
Figura 3.3 apresenta a relação entre os tipos de frameworks.
Figura 3.3 – Representação dos tipos de frameworks (fonte: autor)
3.3 Vantagens e desvantagens
Ao longo das especificações mencionou-se inúmeras vantagens e desvantagens do uso
de um framework, sabe-se que o custo final de um aplicativo de software está diretamente
relacionado ao tempo despendido para concebê-lo. Dessa forma, erros de identificação de
requisitos poderão elevar o custo final do produto. O aspecto mencionado anteriormente
também esta relacionado à escolha das ferramentas que serão utilizadas. Por exemplo, a
escolha do framework a ser adotado no desenvolvimento ou pela escolha de se desenvolver
um próprio framework que realize determinadas funcionalidades comuns a várias aplicações.
As principais vantagens do uso de frameworks são: baixo tempo de codificação, e uso
de soluções já homologadas, além dos desenvolvedores focarem em desenvolver apenas o que
é necessário e principalmente menor probabilidade de erros no código.
As principais desvantagens do uso de frameworks são: necessidade de recursos
humanos especializados, a não disponibilização de todo código fonte que compõe o
framework, mudança de foco no desenvolvimento e a necessidade de desenvolver em uma
linguagem especifica [6].
14
4. FRAMEWORK CORPORATIVO
Para a realização deste trabalho, foi estudado um framework corporativo criado por
uma empresa do setor de desenvolvimento de software. Contudo, o framework em questão
abrange todas as camadas de uma aplicação possuindo, assim, uma complexa arquitetura. A
fim de refinar a pesquisa será abordado apenas a sua camada de persistência, sendo
comparada com o framework NHibernate, próprio para realização de persistência.
O framework corporativo atualmente utiliza ferramentas de mercado como base para
sua construção, como: framework .Net, linguagem de programação C# e IronPython,
plataforma web Asp.net e Silverlight rodando sobre o IIS, Internet Information Service. Ele
permite soluções para diferentes bancos de dados, utilizando como comunicação ADO.Net
(ActiveX Data Objects) para acesso ao banco de dados utilizando conceitos CSLA
(Component-based, Scalable, Logical Architecture) e conceitos do Microsoft Entity
Framework, esse por sua vez realiza apenas persistência como o NHibernate.
O objetivo da empresa ao criar esse framework não foi competir com tecnologias de
mercado, como vimos todas as tecnologias de mercado são utilizadas a fim de criar soluções
de mais alto nível, garantindo maior produtividade e evitando que o setor de desenvolvimento
adote diferentes soluções para diferentes projetos.
Os desenvolvedores da empresa podem utilizar a linguagem de programação C# para
desenvolvimento e manutenção das aplicações da empresa adotando como base o framework
corporativo que fornece vários recursos, inclusive persistência de dados, contudo deverá
manter os padrões estabelecidos pela ferramenta.
4.1 Arquitetura do framework corporativo
A definição da arquitetura para o framework segue os seguintes requisitos:
O desenvolvedor deve ser capaz de programar a regra de negócio da aplicação em C#
não procedural, mantendo os conceitos de OO podendo herdar comportamento de classes do
próprio framework.
O aplicativo deve ser capaz de realizar interoperabilidade com outras tecnologias, ou
seja, aplicativos antigos da empresa não devem ser necessariamente reescritos em C#.
15
Como vimos anteriormente para o uso de um framework faz-se necessário organizar as
aplicações em camadas, esse por sua vez engloba todas as camadas de uma aplicação como
mostra a Figura 4.1, contudo detalharemos apenas a camada de persistência.
Figura 4.1 – Camadas básicas de um aplicativo (fonte: [7])
Para o framework corporativo que iremos estudar, a camada de persistência é uma
mescla de duas camadas vistas acima, são elas: Lógica de negócio e Lógica de acesso a dados,
a seguir demonstraremos um diagrama que compõe toda a estrutura do framework, lembrando
que ele foi concebido a fim de garantir a interoperabilidade entre diferentes tecnologias.
Figura 4.2 - Arquitetura do framework corporativo (fonte: [7])
Se observarmos na Figura 4.2, notamos que regras de negócio escritas em C# podem
ser carregadas e executas a partir de um objeto VBA (Visual Basic) ou diretamente pelo
servidor de aplicação, esse processo já existia anteriormente para regras de negócio escritas
16
em Delphi com a diferença de que as mesmas não poderiam ser acessadas diretamente pela
aplicação desktop, fazendo com que sempre seja utilizado um objeto escrito em VBA.
4.2 Características do framework corporativo
Dentre as principais características do mecanismo de persistência do framework
estudado estão:
Abstrair do desenvolvedor o mecanismos de persistência.
Manter o baixo acoplamento entre o objeto de interação com os dados e a fonte
de dados em si.
Abstrair o controle de LOG de alteração aos dados.
Interagir com os dados através de programação OO, visando assim entre outros
benefícios a reutilização. Por exemplo, classes POCO (Plain Old CLR Object)
podem ser incorporadas em um projeto comum aos demais projetos podendo
assim ser reutilizada ou estendida para se incorporar uma nova regra.
Diminuir o máximo possível à necessidade de o programador escrever
instruções SQL (Structure Query Language) de consulta ou persistência.
Para que todas as características vistas acima funcionem corretamente foi adotada para
esse framework a utilização de “Entidades” para desempenhar a manipulação dos dados
(CRUD - Create, Read, Update and Delete), estas entidades recebem as informações através
de um serviço e esse é responsável em realizar a persistência dos dados efetivamente.
4.3 Processo de criação e utilização do framework corporativo
Esse framework não incorpora todas as funcionalidades de persistência, é comum nos
comerciais permitir ao desenvolvedor criar a aplicação e a partir do mapeamento de suas
classes obterem as entidades do banco de dados, contudo para esse framework não se aplica,
devido ao controle de permissões e acesso além de deixar a cargo dos DBA’s (Data Base
17
Administrator) a padronização e criação de entidades, sendo assim o framework corporativo
não permite aos desenvolvedores utilizar uma abordagem top-down como veremos a seguir.
Para que seja possível criar um projeto é necessário que o framework esteja instalado e
configurado corretamente, a partir daí basta adicionar as DLL’s (Dynamics Link Library) no
projeto C#, as principais são:
EntidadeBase.dll.
EntidadeNegocio.dll.
EntidadeServico.dll.
4.4 Configuração do framework corporativo
A configuração e instalação desse framework é extremamente complexa, pois envolve
a configuração de outros componentes desenvolvidos pela empresa, além disso, ele
compartilha de DLL’s das entidades de serviço com o aplicativo desktop, o que os tornam
interligáveis. Contudo para aplicações web, considerando que esteja tudo configurado e
instalado para os demais componentes, basta configurar o web.config para que ele reconheça
qual o servidor em que se encontra a aplicação.
Por fim a configuração de onde se encontra o banco de dados é realizada através da
própria interface gerada de forma automática pela aplicação, atualmente esse framework
suporta comunicação apenas com os SGBD’s (Sistema Gerenciador de Banco de Dados):
Oracle.
SQLServer 2005.
SQLServer 2008.
DB2.
Cachê.
18
4.5 Mapeamento objeto-relacional
Todo o mapeamento é através de definições de entidades, classes POCO que mapeiam
uma entidade já existente no banco de dados, o framework incorpora várias classes para
realização das associações básicas de um SGBD, sendo assim faz-se necessário ao
desenvolvedor utilizar destas classes para realizar a persistência dos dados, a arquitetura das
classes envolvidas é apresentada abaixo.
Figura 4.3 – Arquitetura das classes e entidades do framework (fonte: [7])
O mapeamento de entidades nada, mas é que relacionar a aplicação com a estrutura do
banco de dados para que seja efetuada a persistência das informações providas da própria
aplicação.
Para agilizar o processo de desenvolvimento incorporado ao próprio framework estão
recursos que permitem ao desenvolvedor gerar as classes POCO.
Como vimos o mapeamento é realizado através de entidades, mas o framework aqui
estudado define como entidade nada, mas do que um objeto de negócio, sendo uma espécie de
caixa preta que contêm os dados e as lógicas de negócio, assim sendo, o desenvolvedor não
necessita conhecer a origem dos dados e nem como as lógicas de negócios são acionadas.
Qualquer tentativa de manipulação dos dados passará através da lógica de negócio,
assegurando que as regras de negócio sempre sejam aplicadas, garantindo a integridade do
objeto de negócio.
19
Através desta arquitetura a entidade não tem conhecimento se está sendo utilizada por
uma interface WinForms, Silverlight, Asp.Net ou por uma regra de negócio no servidor da
camada de negócio, as principais aplicações de persistência são:
Um registro de uma entidade em um banco de dados relacional.
O retorno da execução de uma lógica de negócio.
O retorno de uma stored procedure que obtém dados de diversas entidades.
Tudo que o desenvolvedor precisa fazer é interagir com os objetos referentes às
classes do framework, não se preocupando com transações, persistência, validações, etc.
A classe “EntidadeBase”, como o próprio nome sugere é a base para qualquer
entidade, nela estão as propriedades que mapeiam os campos das entidades e o mecanismo
responsável em realizar de fato a persistência. A seguir tomaremos como exemplo o
mapeamento de uma entidade.
Figura 4.4 – Exemplo de entidade do banco de dados a ser mapeado (fonte: [7])
Figura 4.5 – Objeto POCO instanciado da entidade ACTIVITY (fonte: [7])
20
Como vimos às classes responsáveis em realizar a persistência realizam uma chamada
a um serviço, para isso é necessário que a mesma classe POCO esteja serializada e mapeada
no serviço de entidades do framework, esse processo é automático, a seguir segue a classe
apresentada acima serializada utilizada para execução dos serviços.
Figura 4.6 – Objeto serializado da entidade ACTIVITY (fonte: [7])
Como veremos os relacionamentos de dependência são mapeados através de uma
classe denominada “EntidadeAssociacao”, a mesma realiza o mapeamento um-para-um,
muitos-para-um ou muitos-para-muitos, o que define o tipo de mapeamento é a existência de
outra classe com vínculo do tipo “EntidadeAssociacao”.
Analisando a Figura 4.7 podemos observar a entidade “ACTIVITY” mapeada através
de uma classe POCO do tipo “EntidadeBase”, a mesma classe implementa a interface
INotifyPropertyChanged, porém isto é opcional.
Diferentemente de Java as anotações em uma classe são denominadas como atributos
em C#, partindo desse conceito podemos avaliar o primeiro atributo da classe, o atributo
21
“DefinicaoEntidade” que indica qual é a entidade do banco de dados que será mapeada, em
seguida temos o atributo “Servico” que associa a classe POCO a um serviço criado de forma
automática pelo framework, para isso é passado por parâmetro a URL (Uniform Resource
Locator) e qual a entidade de serviço será executa, em seguida o nome da classe que não
necessita ser o mesmo nome da entidade do banco de dados.
Também podemos observar que a classe estende o comportamento de uma
“EntidadeNegocio” que recebe como parâmetro o tipo a ser mapeado, esse por sua vez se faz
necessário para acessar informações que não estão no domínio da classe POCO, por exemplo,
uma chave estrangeira na classe POCO em si nada mas é do que um valor numérico, sendo
assim para acessar os demais campos da entidade ao qual a chave estrangeira referencia basta
acessar pelo objeto “Fields”, que o framework se encarrega de buscar estar informações
apenas para consulta sem ser necessário mapear esta classe.
São inúmeras as possibilidades através desse mapeamento, as classes POCO’s podem
ser herdadas e para cada método de acesso aos atributos podem incorporar regras e negócio.
Figura 4.7 – Classe POCO da entidade ACTIVITY (fonte: [7])
22
A maneira em que o mapeamento é realizado está diretamente associados às
necessidades da empresa, regras internas são executadas automaticamente o que dificulta
comparar alguns aspectos com outros frameworks, as definições de constraints são
automáticas na classe “EntidadeNegocio”, desta forma o programador não necessita se
preocupar com esse tipo de mapeamento herdado do banco de dados.
23
5. FRAMEWORK NHIBERNATE
O framework NHibernate é semelhante ao framework Hibernate para Java, porém
voltado para tecnologia .Net. Ele lida diretamente com a persistência simples dos dados,
capaz de interagir com diferentes sistemas de gerenciamento de banco de dados.
Seu funcionamento visa a simplicidade, dado um XML (Extensible Markup
Language) de suas entidades e relacionamentos, o NHibernate gera automaticamente o SQL
responsável em armazenar e carregar os objetos, outra vertente é criar classes cujos atributos
serão metadados de mapeamento no próprio código fonte, não sendo necessária a utilização
de um arquivo XML.
Esse framework suporta persistência transparente, ou seja, as classes que representam
objetos a serem mapeados não são obrigatoriamente forçadas a seguir um modelo de
programação restritiva, isso permite projetar a lógica de negócio usando classes .Net simples
[8] denominadas POCO (Plain Old CLR Object).
5.1 Arquitetura do NHibernate
Por meio de uma visão de alto nível da arquitetura do framework NHibernate pode-se
observar a utilização do banco de dados e informações de configuração para que o framework
consiga fornecer serviços de persistência de dados e recuperar objetos já persistidos para a
aplicação.
Figura 5.1 – Visão de alto nível da arquitetura do framework NHibernate (fonte: [9])
24
A seguir temos uma visão mais detalhada da arquitetura em tempo de execução, nota-
se que o NHibernate é flexível e suporta várias abordagens, a arquitetura fornece ao aplicativo
suas próprias conexões ADO .Net e se encarrega de gerenciar suas transações, para isso faz-se
uso de um subconjunto de API’s (Application Programming Interface) do próprio framework.
Figura 5.2 – Visão da arquitetura do framework NHibernate (fonte: [9])
Nota-se que a arquitetura abstrai a aplicação da base ADO .Net deixando os detalhes e
gerenciamento a cargo das API’s do framework. A seguir segue um diagrama contendo todos
os objetos que compõem a arquitetura do framework.
Figura 5.3 – Visão detalhada da arquitetura do framework NHibernate (fonte: [9])
25
Como vimos acima são vários os objetos que compõem sua arquitetura, a seguir temos
a definição de alguns destes objetos e qual a importância de cada um deles.
O primeiro objeto é o Session cujo namespace é NHibernate.ISession, esta é a
principal interface entre a aplicação e o NHibernate, é um objeto de curta duração responsável
por uma comunicação realizada entre o aplicativo e o banco de dados onde serão persistidas
as informações.
O segundo objeto é o SessionFactory cujo namespace é NHibernate.ISessionFactory,
esta interface mantém um cache de todo mapeamento compilado, permite a aplicação criar
sessões a partir do arquivos de configuração, fornecendo um provedor para a conexão através
da interface IConnectionProvider.
As demais interfaces ITransaction, IConnectionProvider, IDriver,
ITransactionFactory são opcionais ao se criar uma aplicação [9].
5.2 Principais características do NHibernate
Dentre as principais características desse framework destacam-se o fato de utilizar um
modelo de programação natural, ou seja, possui suporte a OO e todas as suas características,
além disso, suporta composição de estruturas nativas do .Net como coleções de objetos e
coleções genéricas, dando suporte para uma ampla variedade de mapeamento de coleções e
objetos sem utilizar códigos intermediários durante sua etapa de construção.
O NHibernate garante diferentes formas de como se obter as informações do banco de
dados, para isso é criado o objeto desejado nas consultas para representar um dado ou uma
coleção de dados.
Permite personalizar o SQL tanto para consulta como para persistência dos objetos
mapeados, além disso, permite a execução de alguns procedimentos nativos para quando o
sistema gerenciador de banco de dados utilizado for o Microsoft SQLServer.
Por fim podemos destacar a característica que faz com que seja aceitável a realização
desta pesquisa, esse framework é livre, ou seja, open source e é licenciado sob a LGPL
(Lesser GNU (General Public License) Public License).
26
5.3 Processo de criação e utilização do NHibernate
O processo de criação de uma aplicação que utiliza o NHibernate consiste em etapas
simples, a princípio devemos determinar qual das abordagens utilizaremos com relação a
criação da base de dados, ou seja, devemos determinar se as entidades que irão compor a base
de dados serão criadas a partir da aplicação (top-down) ou se a aplicação será criada a partir
da base de dados (bottom-up).
Não definiremos uma ordem para as etapas de criação, pois as ordens das mesmas se
alteram de acordo com a abordagem adotada na criação da aplicação como mencionado
anteriormente, contudo um projeto que utilize dos recursos do NHibernate deverá conter as
seguintes etapas:
Criação da base de dados e das entidades relacionais.
Criação das classes que irão acessar os objetos mapeados.
Criação do arquivo XML de mapeamento.
Criação do arquivo XML de configuração do NHibernate.
Utilização a API que contém as DLL’s do framework.
É possível eliminar a etapa de criação do arquivo de mapeamento das entidades do
banco de dados devido ao fato do mesmo mapeamento poder ser realizado diretamente na
classe POCO que irá persistir os dados, para que esse mecanismo funcione os atributos das
classes POCO deverão ser identificados através de atributos, estes atributos irão determinar o
comportamento de cada objeto mapeado, como, por exemplo, se ele representa uma chave
estrangeira, se ele possui constraints, se ele representa um chave primária ou qualquer outra
característica provida do mecanismo de um SGBD.
Ao contrário do Entity Framework que já vem incorporado ao Visual Studio, o
NHibernate requer uma instalação manual, para isso basta realizar download do mesmo, e
quando criar um novo projeto adicionar as seguintes DLL’s [8]:
NHibernate.dll.
NHibernate.ByteCode.Castle.dll.
Castle.Core.dll.
27
5.3.1 Abordagem bottom-up
Esta abordagem consiste em criar uma aplicação utilizando o NHibernate para quando
o banco de dados que será persistido já exista, além de possuir sua estrutura de entidades
criadas, isto inclui os relacionamentos entre chaves primárias e estrangeiras, portanto basta ao
desenvolvedor criar uma classe POCO que represente a estrutura da entidade no banco de
dados, criar o arquivo de mapeamento em XML caso não opte em utilizar atributos nos
objetos da classe de mapeamento, criar o arquivo de configuração do NHibernate e adicionar
as DLL’s do framework na aplicação, a Figura 5.4 ilustra o comportamento da abordagem
mencionada acima levando em consideração a utilização de um XML para mapear o banco de
dados ao invés de utilizar atributos nas classes POCO.
Figura 5.4 – Utilização botton-up do NHibernate (fonte: autor)
28
5.3.2 Abordagem top-down
Diferentemente da abordagem mencionada anteriormente, esta por sua vez consiste em
criar um banco de dados a partir das definições realizadas no arquivo XML de mapeamento
ou através das anotações realizadas na definição da classe POCO, além é claro das definições
realizadas nos atributos desta mesma classe, ou seja, a aplicação será responsável em definir
um banco de dados e todas as suas configurações e criar todas as entidades do mesmo bem
como seus relacionamentos de integridade e constraints, a Figura 5.5 ilustra o comportamento
desta abordagem levando em consideração a utilização de um arquivo XML para realizar o
mapeamento.
Figura 5.5 – Utilização top-down do NHibernate (fonte: autor)
5.4 Configuração do NHibernate
Como vimos anteriormente umas das etapas necessárias para utilização desse
framework é a criação de um arquivo XML de configuração, contudo nem sempre se faz
necessária à criação desse arquivo, estas configurações definem informações do provedor,
dialeto, driver e string de conexão do banco de dados usado para persistência.
29
A principio podemos criar o arquivo “hibernate.cfg.xml” e atribuir todas as
propriedades necessárias para que a aplicação conheça o banco de dados, mas como
mencionado anteriormente estas configurações não devem necessariamente conter nesse
arquivo.
Quando chamado o método Configure() do assembly NHibernate.Cfg.Configuration
pertencente a DLL NHibernate.dll já adicionada ao projeto como vimos no processo de
criação, fará com que o NHibernate procure esse arquivo para aplicar as configurações, caso
ele não encontre procurará as mesmas informações nos arquivos de configuração web.config
ou app.config para aplicações web ou desktop respectivamente.
A Figura 5.6 demonstra como ficaria a configuração do NHibernate dentro do arquivo
web.config para uma aplicação web, para isso a tag <ConfigSections> que pertence à
<configuration> deve conter uma nova seção para depois adicionar a configuração do
NHibernate com o nome dessa seção [10].
Figura 5.6 – Configuração do NHibernate dentro do web.config (fonte: [10])
Atualmente os principais bancos suportados pelo NHibernate são: Microsoft SQL
Server 2008/2005/2000, Microsoft Access, Oracle, Firebird, PostgreSQL, DB2 UDB, MySQL
e SQLLite [11].
30
Para alterar o banco de dados a ser utilizado, basta alterar no arquivo de configuração
as tags responsáveis pelo dialeto, provedor, driver e string de conexão, abaixo segue tabela de
configuração dos SGBD’s mencionado anteriormente [11].
Tabela 5.1 – Configuração de banco de dados para o NHibernate (fonte: autor)
SGBD Dialeto Provedor Driver String de Conexão
SQL Server NHibernate.Dial
ect.MsSql2005Di
alect
NHibernate.Connect
ion.DriverConnecti
onProvider
NHibernate.D
river.SqlCli
entDriver
Server=(local);
Initial Catalog=
dbname;User
Id=user;Password=
Microsoft
Access
NHibernate.JetD
river.JetDialec
t,
NHibernate.JetD
river
NHibernate.Connect
ion.DriverConnecti
onProvider
NHibernate.J
etDriver.Jet
Driver,
NHibernate.J
etDriver
Provider=Microsoft.J
et.OLEDB.4.0;
Data Source=
Teste.mdb
Firebird * NHibernate.Dial
ect.FirebirdDia
lect
NHibernate.Connect
ion.DriverConnecti
onProvider
NHibernate.D
river.Firebi
rdClientDriv
er
Server=localhost;
Database=C:nhibernat
e.fdb;
User=SYSDBA;Password
=masterkey
Postgre
SQL
NHibernate.Dial
ect.PostgreSQLD
ialect
NHibernate.Connect
ion.DriverConnecti
onProvider
NHibernate.D
river.Npgsql
Driver
Server=localhost;ini
tial
catalog=nhibernate;U
ser
ID=nhibernate;Passwo
rd=********;
DB2 UDB * NHibernate.Dial
ect.DB2Dialect
NHibernate.Connect
ion.DriverConnecti
onProvider
NHibernate.D
river.OdbcDr
iver
driver={IBM DB2
ODBC
DRIVER};Database=db;
hostname=host;port=p
ort;protocol=TCPIP;
uid=uid; pwd=pwd
MySQL NHibernate.Dial
ect.MySQLDialec
t
NHibernate.Connect
ion.DriverConnecti
onProvider
NHibernate.D
river.MySqlD
ataDriver
Database=test;Data
Source=localhost;
User Id=blah;
Password=blah
* Possuem outras configurações adicionais. * Obs: As strings de conexão deverão ser alteradas de acordo com a aplicação.
5.5 Mapeamento objeto-relacional
O mapeamento de entidades e classes consiste em relacionar de forma direta a
aplicação com o banco de dados onde serão persistidas as informações providas da própria
aplicação, porém para isso é imprescindível que a as classes POCO possuam a mesma
estrutura da entidade ao qual ela representa.
31
Apesar de o mapeamento ser algo simples de se realizar já existem ferramentas
capazes de realizar essa etapa, em busca simples pela internet encontramos uma aplicação
gratuita para realizar o mapeamento da camada de persistência de nossa aplicação,
FluentNHibernate [12] por exemplo, gera um mapeamento fluente do banco de dados.
Esse framework permite a realização do mapeamento de três formas distintas, a
primeira delas através do uso de um arquivo XML, a segunda através de atributos na própria
classe POCO, e uma terceira maneira denominada de mapeamento fluente, que tem como
objetivo utilizar o que tem de melhor das duas outras formas de mapeamento.
A seguir será demonstrada as três maneiras distintas de se realizar o mapeamento do
banco de dados para o NHibernate, para exemplo tomarei como referência a entidade Cliente,
composta pela estrutura abaixo:
Tabela 5.2 – Estrutura da entidade cliente (fonte: autor)
Coluna Chave Primária Tipo Nulo
Id Sim Inteiro Não
PrimeiroNome Não String Não
UltimoNome Não String Não
DataNascimento Não DateTime Sim
Demonstramos como a classe cliente deve ser mapeada em XML para que mantenha a
mesma estrutura e comportamento visto acima, a grande vantagem desse tipo de mapeamento
em XML é que é o mais antigo dentre os três, isto nos leva a crer que esse já tenha atingido
uma maturidade maior para controle de aplicações, dentre as desvantagens está o fato da
configuração não ser algo tão trivial e principalmente pelo fato de se houver alterações no
banco, faz-se necessário alterar esse arquivo e a classe POCO ao qual ele se relaciona.
32
Figura 5.7 – Mapeamento XML da entidade cliente (fonte: autor)
Figura 5.8 – Classe POCO para mapeamento da Figura 6.7 (fonte: autor)
A segunda maneira de mapear a classe Cliente é através da definição de atributos na
classe POCO e em suas propriedades, em Java estes atributos são chamados de anotações.
Esse mapeamento é realizado diretamente na classe, assim não se faz necessária à utilização
de um arquivo XML.
As grandes vantagens desse tipo de mapeamento é que as alterações ficam
centralizadas em apenas um artefato do projeto além de facilitar a compilação do mesmo,
porém a desvantagem é que a classe POCO começa a ficar poluída com muitas linhas de
código deixando-a fortemente acoplada ao framework NHibernate.
33
Figura 5.9 – Classe POCO mapeada da entidade cliente (fonte: autor)
Por fim a última maneira de se realizar o mapeamento no NHibernate, o mapeamento
fluente é a mais recente opção para .Net, trata-se de uma combinação do que a de melhor nos
dois outros mapeamento vistos até então, ou seja, fácil compilação, classes limpas e pequenas.
Figura 5.10 - Classe POCO para mapeamento fluente da entidade cliente (fonte: autor)
Figura 5.11 – Classe de mapeamento para entidade cliente (fonte: autor)
34
É importante ressaltar que o mapeamento deve ser construído em torno da declaração
das classes de persistência e não em torno das entidades do banco de dados [10].
Abordaremos alguns conceitos do NHibernate adotados no mapeamento de uma classe, além
disso ressalta-se que todos elementos, atributos e valores presente em um mapeamento via
XML também constam nos demais tipos de mapeamento visto anteriormente.
5.5.1 Mapeamento de tabelas-classes
Não entrarei em muitos detalhes do funcionamento de todos os atributos desse
elemento, são inúmeras as propriedades que podem ser alteradas para cada atributo e
consequentemente o comportamento da classe também será alterado, os principais atributos
do elemento Class são:
Name, consiste no nome da classe .NET de persistência (ou interface),
incluindo seu assembly.
Table, o nome da entidade ao qual ela se refere no banco de dados.
Schema, permite sobrepor o esquema definido no elemento raiz de
mapeamento.
5.5.2 Mapeamento de chave primária
Classes mapeadas devem declarar a chave primária da entidade de banco de dados. A
maioria das classes também possui uma propriedade com o identificador único de uma
instância. O elemento <id> define o mapeamento desta propriedade para a coluna de chave
primária.
Esse elemento possui os atributos name, type, column, unsaved e access e também
pode possuir um gerador de código específico, para isso deve ser declarado um atributo
generator para ele, para entidades com chave primária composta, deve-se utilizar o atributo
composite-id.
35
5.5.3 Mapeamento muitos-para-um
Consiste em criar uma associação para uma outra classe de persistência, o modelo
relacional que será criado no banco de dados é o muitos para um, alguns dos atributos que
compõem esse elemento são:
Name, o nome da propriedade.
Column, o nome da coluna.
Class, o nome da classe de persistência que será relacionada.
Cascade, é a operação que deve ser realizada para o objeto relacionado ao
objeto pai.
Um exemplo típico de declaração desse mapeamento em XML:
“<many-to-one name="Produto" class="Produto" column="PRODUTO_ID"/>”.
Figura 5.12 – Atributos e valores, mapeamento muito-para-um XML (fonte: [10])
5.5.4 Mapeamento Um-para-Um
Há duas variedades para esse tipo de associação, a primeira delas é a associação de
chave primária e a segunda de chave estrangeira única, para a primeira delas não é necessário
uma coluna extra na entidade. Para uma associação de chave primária, por exemplo, entre a
entidade “Pessoa” e “Empregado”, deve-se realizar o mapeamento mostrado pela Figura 5.13.
36
Figura 5.13 – Mapeamento um-para-um em arquivo XML (fonte: [10])
Garantindo para que a chave primária para as duas entidades sejam sempre iguais, ou
seja, a instância recém-salva de “Pessoa” é então atribuído o mesmo valor chave para a
instância “Empregado”, de forma alternativa podemos realizar esse mesmo tipo de
relacionamento da seguinte maneira:
“<many-to-one name="Pessoa" class="Pessoa" column="PESSOA_ID"
unique="true"/>”.
Esta associação passa a ser realizada de forma bidirecional, adicionando a seguir para
o mapeamento de “Pessoa”.
“<one-to-one name="Empregado" class="Empregado" property-ref="Pessoa"/>”.
Figura 5.14 – Atributos e valores, mapeamento um-para-um XML (fonte: [10])
37
6. COMPARAÇÃO DOS FRAMEWORKS
O fato do uso de um framework como base para a construção de um aplicativo de
software traz inúmeras vantagens ao processo de desenvolvimento, entre elas podemos citar a
produtividade da equipe, a capacidade da aplicação de agregar novos recursos, o aumento da
capacidade de alteração em recursos já desenvolvidos e por fim o fato de que em sua maioria
os frameworks já possuem um alto nível de maturidade com relação a vários aspectos, como
por exemplo, efetividade no mapeamento de uma base de dados.
Esta seção apresenta a comparação realizada entre o framework NHibernate e o
framework corporativo. Para isso foram comparados os aspectos de persistência de ambos
para identificar o quanto eles influenciam na produtividade de uma equipe de persistência,
levando em consideração a capacidade que ambos apresentam com relação ao crescimento de
uma aplicação e principalmente o impacto causado por alterações de funcionalidades já
desenvolvidas. Para levantamento dos aspectos mencionados foi aplicado um questionário,
Apêndice A, junto a desenvolvedores e analistas que trabalham com ambas as tecnologias a
fim de levantar as dificuldades, vantagens e limitações com relação ao uso de ambos os
frameworks.
A produtividade de uma equipe de desenvolvimento de software está diretamente
relacionada ao tempo desprendido na criação do software com relação à quantidade de
recursos adicionados ao desenvolvimento.
O uso de um framework aumenta consideravelmente a produtividade por permitir
reutilização de código fonte e por fornecer classes e interfaces com mecanismos já
implementados, contudo identificar o que pode ser ou não comum a vários projetos para que
sejam desacoplados da aplicação a fim de serem reutilizados em outras circunstâncias faz com
que o desenvolvedor tenha um nível de abstração maior com relação às regras de negócio e
principalmente com relação às ferramentas que ele utilizará [6].
Como citado anteriormente podemos definir produtividade como sendo a relação de
recursos disponíveis por tempo gasto, mas por se tratar de serviços de software deve-se levar
também em consideração a qualidade, eficácia e eficiência dos serviços oferecidos pela
empresa de TI (Tecnologia da Informação).
38
Com base nas informações coletadas no decorrer desse trabalho podemos mensurar o
quão produtivo pode se tornar o ciclo de desenvolvimento de um aplicativo de software ao
utilizar o framework corporativo ou o framework NHibernate, podendo chegar a conclusãode
qual entre ambos é mais efetivo.
É possível observamos que para os frameworks atingirem o máximo de sua
produtividade é interessante, porém não obrigatório que a aplicação que faça uso dos de tais
frameworks esteja também arquitetada de maneira correta. A aplicação deve estar organizada
em camadas como, por exemplo, sugerido pelo modelo MVC a fim de possibilitar na camada
modelo o uso de um framework de persistência de dados.
Com base nos dados coletados pelo questionário aplicado junto aos desenvolvedores e
analistas de sistemas que utilizam do framework NHibernate [Apêndice A] obtemos o gráfico
da Figura 6.1 referente a questão um do questionário, que demonstra o tempo estimado pelos
desenvolvedores para começar a produzir em nível satisfatório, ou seja, através do uso do
NHibernate os desenvolvedores devem ser capaz de realizar o mapeamento objeto-relacional
(atributos e entidades), realizar querys complexas, realizar a persistência dos dados, estruturar
suas classes POCO utilizando das práticas de OO (herança, encapsulamento, polimorfismo,
abstração e coesão) e estruturar a aplicação garantindo o controle de transação oferecido pelo
framework.
Figura 6.1 – Tempo de adaptação do usuário do NHibernate (fonte: autor)
39
Como observamos na Figura 6.1 sessenta por cento dos desenvolvedores usuários do
NHibernate não levaram mais do que trinta dias de estudos e treinamentos para integrar uma
equipe de desenvolvimento utilizando o framework NHibernate de forma efetiva, ou seja,
começar a produzir de forma satisfatório como definido acima.
É comum no ambiente de desenvolvimento de software os recursos humanos levarem
mais tempo para se adaptarem ao processo de trabalho devido ao curto tempo entre o
surgimento de novas tecnologias, desta forma podemos afirmar que o tempo de aprendizagem
do NHibernate é de certa forma considerado baixo o que viabiliza a adoção do mesmo.
A seguir temos o demonstrativo do tempo estimado pelos desenvolvedores usuários do
framework corporativo estudado neste trabalho.
Figura 6.2 – Tempo de adaptação do usuário do framework corporativo (fonte: autor)
Podemos observar que o tempo médio para que um desenvolvedor comece de fato a
produzir utilizando o framework corporativo é muito maior do que tempo demandado
NHibernate. Um dos principais motivos alegados pelos desenvolvedores é a falta de
documentação apropriada, além de não existir conhecimento na comunidade de software com
relação a tal framework.
É comum no decorrer do processo de criação de um aplicativo nos deparar com novos
requisitos que talvez não tenham sido implementados pela equipe em nenhum momento.
Dessa forma, cabe aos programadores de sistemas desenvolverem uma solução ou buscar por
40
experiências fora do ambiente de trabalho. Contudo, para o framework corporativo esse tipo
de recurso não se aplica, o que afeta diretamente a produtividade dos programadores.
Portanto, existem fortes indícios de que o framework NHibernate é de fato mais
produtivo que o framework corporativo. Porém, outros aspectos devem ser analisados para
tornar o framework corporativo mais prático mesmo sendo pouco produtivo. Um aspecto
simples é restringir ao DBA a criação das entidades e campos no banco de dados, esse aspecto
varia de acordo com as regras e padrões da própria empresa que o utiliza.
A seguir temos um quadro comparativo com relação às ações de persistência capazes
de serem executadas pelos frameworks aqui comparados.
Tabela 6.1 – Comparação das ações de mapeamento dos frameworks (fonte: autor)
Framework Consulta Inserção Gravação Remoção Criação
Corporativo Sim Sim Sim Sim Não
NHibernate Sim Sim Sim Sim Sim
Com base na Tabela 6.1 podemos notar que o framework corporativo não incorpora ao
seu mecanismo de persistência a criação de entidades e campos a partir de suas classes
mapeadas. Isso não pode ser considerado uma deficiência pelo fato de que ele foi concebido
com esse intuito para garantir as regras do processo de criação de aplicações da empresa que o
criou. Se pensarmos nesse cenário, podemos chegar a conclusão de que o NHibernate não
atenderia tal necessidade pelo fato de permitir ações de criação.
Para que um framework seja passível de ser utilizado um dos principais requisitos que
ele deve suprir é a escalabilidade, ou seja, a capacidade que ele possui em suportar o aumento
de consumo de seus recursos [6]. Como esta pesquisa contempla frameworks de persistência
de dados e que cada requisição feita ao banco de dados irá utilizar seus recursos, logo
podemos definir que o aumento de uso de recursos do framework estará diretamente
relacionado com o aumento de acesso a base de dados, independentemente da ação a ser
executada.
Ambos os frameworks dão suporte a uma grande gama de requisições, o consumo de
memória de ambos é satisfatória para gerenciar uma requisição de acesso ao banco de dados,
41
ou seja, não há aumento gradativo de consumo de memória a cada iteração (Session,
Transaction), pois ambos não apresentam vazamento de memória, sendo assim o garbage
collector do framework .Net consegue limpar da memória o que não está mais em uso. Assim,
os recursos de hardware do servidor limitam de fato o quão escalável é o framework.
Como mencionado anteriormente o framework corporativo incorpora um serviço de
entidades para permissão de usuários em cada entidade do banco de dados, logo seu consumo
de memória é maior se comparado com o NHibernate, por exemplo, para cada persistência
que ele for realizar será necessário realizar consultas em outras entidades para identificar se
aquele usuário possui uma definição de nível de acesso com permissão de gravação para a
entidade a ser persistida.
Por fim devemos avaliar o quão adaptáveis são ambos os frameworks, ou seja, eles são
capazes de suportar mudanças consideráveis no meio de um ciclo de vida de uma aplicação
sem impactar diretamente no que já foi desenvolvido, por exemplo:
Mudanças com relação ao SGBD.
Mudanças com relação à plataforma onde o aplicativo será mantido, ou ainda
troca ou atualização do sistema operacional.
Mudanças com relação às regras de negócio.
Notamos que o NHibernate dá suporte a mais SGBD’s que o framework corporativo, é
claro que isso se dá ao fato de que a empresa que desenvolveu seu próprio framework
corporativo o criou para atender apenas aos SGBD’s ao qual trabalha.
Tabela 6.2 – SGBD’s suportador por ambos frameworks
Framework Oracle SQLServer Firibird Access PostgreSQL DB2 MySQL SQLLite Cachê
Corporativo Sim Sim Não Não Não Sim Não Não Sim
NHibernate Sim Sim Sim Sim Sim Sim Sim Sim Não
É comum com o passar do tempo regras de desenvolvimento serem alteradas. É
possível pensar em um cenário onde o serviço de entidades do framework corporativo
necessite sofrer alterações, lembrando que nem todos os usuários desse framework possuem
acesso às classes que o compõe, pois existe uma equipe responsável para fazer isso. Se essas
42
mudanças englobarem novas implementações, com o passar do tempo tendem a surgir o que
chamamos de código morto [7], ou em um pior caso códigos sendo executados sem a menor
necessidade. Assim sendo, essas características tendem a elevar muito o custo de se criar um
framework corporativo.
Portanto, construir algo que agregue recursos às aplicações deve sempre levar em
consideração as possíveis alterações que ele irá sofrer. Quando optamos em usar o
NHibernate somos sempre forçados a desenvolver qualquer regra que não seja relacionada
com a persistência de dados. Essas regras variam de acordo com o projeto. Para os estudos
realizados neste trabalho podemos identificar que o framework corporativo apesar de realizar
persistência de dados incorpora regras de autenticação automática, e isto faz com que
mudanças realizadas nele afetem todos os projetos que o utilizam.
43
7. CONCLUSÃO E TRABALHOS FUTUROS
Através dos estudos realizados em cima da arquitetura de dois frameworks de
persistência de dados, sendo um deles corporativo e o outro open source, fomos capazes de
determinar qual seria o ideal a ser adotado. Para isso levamos em consideração as
características de mapeamento, opinião de profissionais que atuam com ambos os
frameworks, aspectos relacionados a mudanças e escalabilidade.
Através das comparações realizadas identificamos que o framework corporativo possui
regras acopladas a persistência de dados, tornando impossível desacoplar de suas
funcionalidades esse controle de permissões, além disso, notamos que ele atualmente limita o
mapeamento objeto-relacional apenas por meio de classes POCO’s, não permite ações de
criação na base de dados e por fim identificamos que o mesmo dá suporte a uma gama menor
de SGBD’s se comparado ao NHibernate.
Com base nas informações obtidas neste trabalho com relação aos frameworks e com
as comparações e aspectos levantados podemos concluir que o NHibernate atende melhor as
necessidades da empresa com relação a produtividade pelo fato de não acoplar mecanismos de
permissão automáticos para cada iteração de persistência que realizar, deixando a cargo do
desenvolvedor escolher quando executar ou não esse tipo de funcionalidade.
Nota-se que o NHibernate fornece a seus usuário formas distintas de se realizar o
mapeamento objeto-relacional. Ele possui uma documentação melhor elaborada, permite
ações de criação na base de dados a partir de seu mapeamento e tem como pré-requisito o
conhecimento de OO e conhecimento de relacionamentos entre entidades do banco de dados.
Portando, baseado nos resultados identificamos que para qualquer tipo de aplicação o
uso do NHibernate é extremamente aconselhável, tornando a criação/uso de um framework
corporativo prejudicial no mínimo questionável com relação ao tempo que será desprendido
na criação do mesmo, adaptação e treinamento de profissionais, confiabilidade, adaptação a
mudanças e capacidade de crescimento.
O framework corporativo pode agregar regras à persistência como é o que ocorre com
o serviço de entidades já mencionado. Porém, tais regras podem ser desenvolvidas utilizando
o NHibernate, desacoplando da persistência. Isso despenderia mais tempo na criação, mas se
levarmos em consideração o tempo que a construção de uma tecnologia corporativa leva além
de consumir muitos recurso de uma empresa, torna-se aceitável a utilização do NHibernate
para cenários como os apresentados neste trabalho.
44
Ambos os frameworks são eficazes com relação à persistência de dados, contudo para
este trabalho não foi possível comparar a eficiência de ambos, esta limitação ocorreu devido
ao fato de que o framework corporativo executa um serviço de entidades a cada ação de
persistência solicitada a ele, esse serviço de entidades tem como objetivo verificar se o
usuário possui permissão para realizar ações CRUD em determinada entidade do banco de
dados, sendo assim qualquer comparação de desempenho passa a ser inconclusiva, uma vez
que instruções SQL são sempre adicionadas ao mecanismo de persistência do framework
corporativo.
O desenvolvimento deste trabalho de pesquisa buscou acrescentar conhecimento à
comunidade de desenvolvimento de software com relação à utilização de frameworks
terceirizados de persistência de dados como o NHibernate se comparado com a construção de
um framework corporativo, possibilitando destacar as seguintes contribuições:
benefícios na utilização de um modelo de arquitetura de projeto de software em
camadas ao se utilizar um framework de persistência de dados;
identificação dos principais riscos a se optar em construir um framework
corporativo de persistência de dados;
complexidade da arquitetura que envolve a construção de um framework
corporativo;
principais vantagens em optar pela utilização do NHibernate; e
Comparações para identificar qual o melhor modelo de framework a ser
adotado na construção de um aplicativo de software, levando em consideração
os requisitos que o software deve apresentar.
Existem alguns pontos deste trabalho que podem ser estendidos com o objetivo de
acrescentar mais detalhes de comparação de ambos os frameworks. Dentre as sugestões de
trabalhos futuros é possível citar:
Construir uma aplicação utilizando o NHibernate que simule a execução do
serviço de entidades do framework corporativo, a fim de mensurar com
exatidão a diferença de desempenho de ambos ao executar a persistência de
dados;
Submeter o framework corporativo a uma mudança de regras do serviço de
entidade para analisar o impacto real que sofrerão todas as aplicações que
façam uso dele; e
45
Além da limitação com relação ao desenvolvimento de uma aplicação com ambos os
frameworks para comparar desempenho, podemos identificar como uma outra limitação o
levantamento dos custos financeiros com relação ao desenvolvimento de uma ferramenta
corporativa, comparando com a adoção de utilizar uma ferramenta open source e investir em
treinamento aos recursos humanos.
46
REFERÊNCIAS BIBLIOGRÁFICAS
[1] ALEXANDER C.; ISHIKAWA S.; SILVERSTEIN M.; JACOBSON M.; FIKSDAHL
KING I.; ANGEL S.; A Pattern Language. Oxford University Press, New York, 1977.
[2] FREEMAN, E.; SIERRA, K.; BATES B. Use a Cabeça: Padrões de Projetos. Segunda
Edição. USA: O’Reilly Media, 2004.
[3] GAMMA, E.; HELM R.; JOHNSON R.; VLISSIDES J. Design Patterns. Elements of
Reusable Object-Oriented Software. Professional Computing Series. Massachusetts, USA:
Addison-Wesley, 1995.
[4] BASS L.; CLEMENTS P.; KAZMAN R.; Software Architecture in Practice. USA:
Addison-Wesley, 1998.
[5] ECKEL, B. Thinking in Patterns. Problem-Solving Techniques using Java. Revision
0.9. 0.9 ed. President, USA : MindView, 2003.
[6] FIORINI, S. T. Arquitetura para Reutilização de Processos de Software. 2001. Tese
(Doutorado em Informática) - Pontifícia Universidade Católica do Rio de Janeiro, Rio de
Janeiro.
[7] Framework Corporativo. Documentação do Framework Corporativo.
[8] NHibernate, <http://www.nhibernate.com/>. Site oficial do framework NHibernate,
acessado em 15/12/2011.
[9] NHibernate, <http://nhforge.org/wikis/reference2-0en/architecture.aspx>. Definição
de arquitetura do NHibernate, acessado em 08/01/2011.
[10] NHibernate, <http://nhforge.org/doc/nh/en/index.html>. Documentação técnica do
NHibernate, acessado em 08/01/2011.
[11] NHibernate, <http://imasters.com.br/artigo/20695/banco-de-dados/ nhibernate-
banco-de-dados-suportados-pelo-nhibernate>. Principais SGBD’s suportados pelo
NHibernate, acessado em 08/01/2011.
[12] NHibernate, <http://fluentnhibernate.org/>. Ferramenta para mapeamento fluente de
objeto-relacional, acessado em 08/01/2011.
47
APÊNDICE A – QUESTIONÁRIO FRAMEWORKS
1. Qual o tempo médio que o programador leva para começar a produzir ao adotar a
utilização deste framework?
[ ] 30 dias [ ] 45 dias [ ] 60 dias [ ] acima de 60 dias
2. Com relação ao nível da documentação oficial deste framework, você a considera?
[ ] baixo [ ] média [ ] alto
3. Para o framework em questão como você classificaria o conhecimento na comunidade
de software?
[ ] não existe [ ] baixo [ ] médio [ ] alto
4. Qual a relação de exemplos práticos disponíveis para ser tomado como base no
processo de aprendizado deste framework.
[ ] nenhum [ ] poucos [ ] suficientes [ ] vários
5. Com relação à complexidade das classes e interfaces deste framework você considera?
[ ] simples [ ] complexas
6. Com relação ao mapeamento objeto-relacional, o framework pode ser considerado?
[ ] insuficiente [ ] suficiente
7. Com relação à restrição como é feita o mapeamento objeto-relacional, o framework
pode ser considerado?
[ ] baixa [ ] média [ ] alta
8. Qual a dificuldade de incluir uma nova regra a classe POCO, ao se utilizar deste
framework?
[ ] baixa [ ] média [ ] alta
9. Qual a importância de uma arquitetura bem definida para a utilização deste
framework?
[ ] pouco importante [ ] importante [ ] muito importante [ ] indispensável
10. Com relação a alterações na base de dados, replicar para o aplicativo ao se utilizar
deste framework pode ser considerado?
[ ] simples [ ] complexo
