CONCEITO DE UTILIZAÇÃO DE MULTIPLOS DATA MODULES
Como foi examinado no artigo anterior, existem vantagens e desvantagens na utilização de uma abordagem de um único Data Module em uma aplicação Client/Server. Outra abordagem a ser analisada é a de vários Data Modules, onde poderemos nos referir como Data Module baseados em entidades. Nessa abordagem os Data Modules separados são criados para encapsular uma única funcionalidade.
Vamos analisar toda a funcionalidade relacionada aos clientes onde deverá ser armazenada em um Data Module de cliente (customer). Dessa forma teríamos algumas vantagens em relação à abordagem anterior. Primeiramente, os Data Modules separados permitem que a funcionalidade seja tratada como entidades gerenciáveis. Vamos examinar o mesmo aplicativo, mas com a abordagem de Data Modules baseados em entidades. Neste exemplo temos vários Data Modules separados, cada um encapsulando a funcionalidade apropriada.
Figura 1 - Imagem do Data Module com componentes úteis e a conexão com o banco.
Pode-se observar que os únicos componentes colocados neste Data Module (dtmdlPrincipal) foram os de integração com o projeto em si: o TSQLConnection (sqlcnctnMaster), TSQLDataSet (sqldtstMaster), TDataSetProvider (dtstprvMaster) que fazem a integração com o banco de dados. Separando tais componentes dos DataSets - TClientDataSet, muitos dos problemas normalmente associados a herança do Data Module serão resolvidos.
Além disso, uma vez que os componentes estão relacionados diretamente com os DataSets, poderemos separá-los em seu próprio Data Module. Nestes Data Modules iram ser incorporados à funcionalidade de cada entidade. Neste caso iremos mostrar o dtmdlCustomer com a funcionalidade da entidade Customer (Cliente).
Figura 2 - Imagem do Data Module com a funcionalidade da entidade Customer.
Em dtmdlCustomer, incluímos todos os componentes necessários para obter a funcionalidade associada aos Customers (Clientes). Qualquer regra de negócio anexada aos manipuladores de evento também será incorporada aqui. Observe que clntdtstSales foi incluído no dtmdlCustomer, isso porque o componente clntdtstSales esta apontando para o clntdtstCustomer em um relacionamento de vendas (sales) com clientes (customer).
No bando de dados, a tabela Sales o campo CUST_NO é um foreign key (chave estrangeira) que aponta para o campo CUST_NO da tabela Customer. No aplicativo, a tabela Sales é a única a ser vinculada com Customer, logo a incluímos no dtmdlCustomer. Também incluímos no dtmdlCustomer a stored procedure sqlstrdprcShipOrder que atualiza os campos de status das vendas realizadas aos clientes, controle necessário para a entidade Customer.
Agora que toda a funcionalidade de clientes foi separada, o mesmo pode ser feito para Employee, Job, etc. Isto dará aos desenvolvedores um controle maior sobre a criação das instâncias dos componentes. Não serão necessárias outras instâncias de componentes onde o usuário estiver utilizando unicamente informações de clientes. Os componentes são agora subclassificados em relacionamentos de entidades em escala.
Esta abordagem irá aperfeiçoar a utilização dos recursos de servidor e diminuir o tráfego da rede. Resumindo, o desempenho de um aplicativo poderá ser melhorado em grande escala por meio da utilização de Data Modules baseados em entidades de banco de dados. Apesar de tal abordagem aumentar um pouco a utilização de recursos quando todas as entidades são necessárias ao mesmo tempo, as vantagens da encapsulação, em termos de desenvolvimento e manutenção de aplicativos, superam de longe quaisquer desvantagens existentes.
CONCLUSÃO GERAL
Examinamos as vantagens e desvantagens de abordagens no uso de Data Modules em aplicações Client/Server. Com a abordagem de Data Module único, todas as entidades e regras de negócios permanecem em um único lugar. Já, com os Data Modules separados por entidades e regras de negócios estão subclassificados de acordo com sua funcionalidade. Um conceito importante dentro da Programação Orientada a Objetos (Object-Oriented Programing – OOP) é a encapsulação. Se seguirmos ao pé da letra este recurso de programação, a abordagem de Data Modules separados é a mais apropriada.
Detalhe importante a ser comentado quanto a utilização de Data Modules separados por entidade é quanto a arquitetura Multitier. Quando a Borland à introduziu no Delphi 3, foi chamado MIDAS (Middle-tier Distributed Application Services). Depois a Borland renomeou a tecnologia para DataSnap e estendeu suas capacidades para web. A partir do Delphi 7 Enterprise você não precisa mais pagar a taxa de instalação para aplicações de DataSnap.
Adquirindo o ambiente de desenvolvimento se pode instalar seus programas em quantos servidores seja preciso, sem a necessidade de pagar qualquer quantia a Borland (hoje Embarcadero). Esta foi uma mudança muito significativa (a mais significativa no Delphi 7) à apólice de distribuição do DataSnap, que exigia uma taxa por servidor (inicialmente muito alto, então significativamente abaixado com o tempo) e hoje isenta de valores. Esta licença de instalação certamente aumentou o apelo de DataSnap aos empresários, o que é uma boa razão para incluí-la em suas aplicações Client/Server e aplicar a abordagem de Data Modules separados por entidades.
Outra observação importante é que você pode criar uma aplicação de Servidor Web com seus Data Modules existentes. Para isso basta você adicionar um componente TWebDispatcher (localizado na aba Internet da paleta de componentes do Delphi) a ele convertendo-o assim a um WebModule. Isto é uma boa técnica se quiser converter uma aplicação Delphi existente em uma extensão de web server.
Apesar de ser para muitos bem óbvio estas abordagens, espero ter de alguma forma sanado muitas dúvidas referentes a utilização de Data Modules. Claro que qualquer informação que tenha deixado passar e o caro leitor queira me enviar para agregar a este conteúdo, será muito bem vinda.
Grande abraço... e até mais!!!
