|
Usuários |
|
140 Usuários Online
|
|
[Artigos]
Você Sabe o que é um Framework? |
Publicado por rboaro : Quarta, Janeiro 30, 2013 - 08:26 GMT-3 (716 leituras)
 2 Comentários  Enviar para um amigo  Versão para impressão
|
Framework nada mais é que uma "caixa de ferramentas". Um Framework .NET é uma caixa de ferramentas ( Bibliotecas ) prontas para trabalhar com .NET. O Framework VCL ( sim ele pode ser chamado assim ) é uma coleção de componentes
que trabalham de forma visual sobre o Windows. Framework nada mais é que uma coleção de objetos e classes destinadas a executar determinada tarefa.
Um Framework "ORM" é uma coleção de objetos/classes que tende a facilitar o desenvolvimento Obejto Relacional em um Sistema.
Como podemos ter Framework Web, DS, etc,etc,etc...
Para quem vem do Clipper ... é como se cada LIB ou Library ( Nantucket Tools, CA-Tools ) fosse
um framework.
Para aqueles acostumados com Delphi é como se cada "parte" da VCL inclusa na IDE fosse um Framework ( Quickreport = FW para relatórios, RAVE = FW para relatórios, INDY = FW para Comunicação/Internet, TDBF = FW para acesso direto a DBF’s, ect, ect, ect.. ) e pacotes como a JEDI, RX, RDPrint, são frameworks diferentes, algumas vezes com a mesma finalidade mas com aspectos diferentes.
Voltando ao ORM existem vários ORM disponíveis que não passam de "sabores" para desenpenhar
a mesma premissa : Mapeamento Objeto Relacional.
O que é um mapeamento Objeto Relacional? Eis o X da questão. É uma forma de se possuir um Objeto "Cliente" que possa ser atualizado em um banco de dados ( SGDB ) ou Banco Relacional ( SGDBR ).
SGDB = Sistema Gerenciador de Banco de Dados
SGDBR = SGDB + Relacional
Nem todo sistema de banco de dados é relacional.
Relacional implica em dizer que parte da tarefa do Banco de dados é manter a integridade Referencial entre seus pares. O MySQL até versões anteriores a 4 não era relacional. Apenas um SGDB.
( me corrijam se estou errado ).
Os SGDB reconhecem apenas os conceitos TABELAS/COLUNAS enquanto que um SGDBR faz a ligação de uma tabela/coluna com outra tabela/coluna dizendo que um dado existente em uma delas depende de outra. Em um SGDBR, algumas regras de negócios são aplicadas no SGDB de forma a garantir uma integridade referencial ( um Cliente não pode ser excluído caso tenha pedidos, ou um Pedido deve excluir todos seus itens ).
O ORM transfere parte desta regra para a aplicação fazendo com que um Objeto "Cliente" cheque
se o mesmo possúi pedidos antes de ser excluído. Ou fazendo com que o Objeto "Pedido" exclua seus
itens antes de ser excluído. Percebemos que neste ponto possuímos uma dupliciade de validações do ORM quanto do SGDBR, mas que o mesmo irá funcionar em um SGDB. Isto torna o Sistema mais confiável e apto a ser utilizado com qualquer SGDB mesmo que não Relacional. Em um SGDBR um "Sistema de faturamento" ( um módulo ) pode validar a nível de banco de dados ( Triggers, Procedures, e Constraints ) se o "Sistema financeiro" já incluíu alguma informação.
Em um SGDB "simples" estas premissas estão a cargo do sistema. Tratar tudo via o SGDB Relacional pode ser de extremo custo a manutenção das regras básicas de negócio visto que elas estarão "perdidas" entre triggers/procedures do mesmo e a portabilidade será reduzida pois cada banco possúi sua sintaxe e recurso expecíficos.
Um ORM nada mais é que uma forma de tratar todas as regras de negócido a nível de sistema,
onde cada operação é validada antes de ser executada:
ex : Excluir cliente, pode se não tem pedidos. Se excluir pedidos, tem que excluir os Itens.
O ORM vem para auxiliar a manter estas regras em um único lugar ( no caso a aplicação ).
Um objeto Cliente, ao receber um "delete" checa as regras de negócio ( tem pedidos ? ) antes
de poder ser deletado. Um objeto Pedidos tenta excluir todos os itens antes de ser "deletado".
As implementações a nível do SGDB Relacional podem continuar, possibilitando que o sistema seja mais confiável. Mas se o sistema não for baseado em um SGDB Relacional, o sistema garantirá sua
funcionalidade.
Aqui podemos citar uma nova (velha) confusão : DAO = Data Access Object.
DAO é para servir de CRUD ( Create, Read, Update, Delete ) de uma tabela e também possibilitar
níveis de acesso as informações.
Um framework DAO fará todas as validações antes supostas serem do ORM.
A grande diferença entre os dois esta na premissa que o DAO realizará o CRUD e a checagem da integridade refencial, enquanto que o ORM pode se usufluir do DAO e manter regras mais específicas ao "negócio", como um cliente não pode inserir um
pedido se seu saldo é negativo.
O FW ORM poderá tratar diversas regras de negócio não apenas na questão relacional. Por vezes o ORM se sobrepoe ao DAO ou tem o mesmo incorporado, mas mantendo as funcionalidade distintas.
DAO = CRUD + Integridade Referencial.
ORM = DAO + Regras de negócio.
O grande paradigma para programadores Delphi é se abser das chamadas Tables ( CDS, Query, IBTables, XXXTable, XXXQuery ), que propiciam CRUD de froma direta em qualquer lugar, em função de um Objeto que é inicializado por uma única "unit" e deverá ser utilizado em todas as operações CRUD para manter as regras de negócio e a integridade de forma centralizada.
Caique Rodrigues
Desenvolvimento e suporte a Desenvolvedores
Delphi Win32/64 - Firebird
Embarcadero MVP - Community Evangelist
|
|
 Comentários | |
| | Comentários pertencem aos seus respectivos autores. Não somos responsáveis pelo seus conteúdos. |
por: cliodao (cliodao@gmail.com)
: Fev 04, 2013 - 10:48
(Informações sobre o membro | Enviar uma mensagem)
http://http://
|
|
Olá Caique. Parabéns pela contribuição, ela já foi suficiente para sanar parte de minhas infinitas dúvidas ! Agora falando em termos práticos, quando eu programo de forma orientada a objetos, com uma "unit" para cada "objeto", contendo as regras de negócios dos mesmos e, um data-module com as funções CRUD, eu posso dizer que esse conjunto descrito funciona como um FW ORM?? Ou não seria nada disso? Abraço;
|
|
|
Edição 112 |
|
|
50 Programas Fontes |
|
|
Produtos |
|
|
