Capítulo 6

No capítulo anterior geramos a GUI da aplicação. Para tanto, utilizamos o RSClass – Gerador de Classes e, assim, as páginas web foram produzidas aptas a realizar as operações básicas de inclusão, alteração, exclusão e consulta. A esta aplicação chamamos ou chamaremos de ‘protótipo’. Inclusive é como o RSClass – Geração de Classes denomina.

Enfim, o protótipo foi todo gerado, completamente funcional, em camadas e até o momento, não escrevemos nenhuma linha de código ou fizemos qualquer interferência nos arquivos gerados. Obviamente muito ainda há pra ser feito e a principal atividade é implementação das regras de negócio; aquelas que definimos no primeiro post. Não lembra? Segue abaixo.

…todos possam acessar, cadastrar, alterar, consultar e listar contatos. Mas, para ter acesso a agenda, cada usuário precisaria de uma senha. Uma regra importante é que somente o usuário que cadastrou o contato pode ter a permissão para excluí-lo. Porém, todos podem alterar, listar e consultar qualquer contato registrado. Se um contato for definido como confidencial, somente o usuário que cadastrou teria o direito a visualizar, modificar, consultar ou excluir. Se um usuário for excluído, seus contatos passam a ser de domínio público, ou seja, todos ganham o direito de gerenciar os contatos do usuário excluído.

Contudo, neste momento estamos mais interessados em trabalhar na arquitetura e é isso que vamos fazer agora. Para entender melhor o que vamos fazer é importante ler o seguinte material: RemoteServer.NET. Resumidamente, ele propõe a utilização de um servidor para aplicação distribuída, ou seja, um esquema onde partes da aplicação são executadas em servidores diferentes. O conceito envolvido é o de ESCALABILIDADE que siginifica “capacidade de manipular uma porção crescente de trabalho de forma uniforme, ou estar preparado para crescer.” Esta definição bem como outras informações a respeito podem ser encontrados aqui.

O RemoteServer.NET é uma aplicação que pode ser utilizada juntamente com nossas aplicações para implementar o processamento distribuído; utilizando um servidor de aplicação. Quem adquiriu o RSClass – Geração de Classes também recebeu de brinde esse aplicativo incluindo seu código-fonte. Na pasta de instalação do RSClass – Geração de Classes voce encontrará esse aplicativo. A seguir, vamos configurar o nosso aplicativo web da Agenda Telefônica para utilizar esse recurso. Mas insisto na importância da leitura mencionada acima antes de continuar.

A arquitetura que queremos implementar é como mostrado na figura abaixo: um servidor web que receberá requisições dos clientes via HTTP e outro, que será o servidor da aplicação que responderá sobre as regras de negócio. Os BOs, os DAOs e o banco de dados estarão neste servidor. Lembrando que os DTOs ou ORs são as classes que farão o transporte das informações entre o servidor web e o servidor de aplicação.

ArquieturaAgendaTelefonica

Se voce não possui dois computadores em rede pra testar a arquitetura, não tem problema. Vamos simular tudo aqui em uma única máquina. O fato é que deve haver um servidor de aplicação apto a receber requisições do servidor web, mesmo que os dois serviçoes sejam realizados pelo mesmo computador. Então vamos começar os trabalhos.

Primeiramente, instale o RemoteServer.NET. Voce encontrará o instalador de uma das seguintes maneiras:

  1. Se voce adquiriu o RSClass – Geração de Classes, recebeu também a solução com o código-fonte e o instalador já gerado. Localize a pasta ‘{Pasta de instalação do RSClass}\Projeto RemoteServer\RemoteServerSetup\RemoteServerSetup\Express\DVD-5\DiskImages\DISK1’ a execute o instalador ‘RemoteServer.Net.msi’.
  2. Se voce adquiriu o RemoteServer.NET exclusivamente, também recebeu a a solução com o código-fonte e o instalador já gerado. Localize a pasta ‘{Pasta de descompactação do RemoteServer.Net}\Projeto RemoteServer\RemoteServerSetup\RemoteServerSetup\Express\DVD-5\DiskImages\DISK1’ a execute o instalador ‘RemoteServer.Net.msi’.

O RemoteServer.NET será instalado no seu computador para ser utilizado em uma das seguintes formas: serviço do Windows ou aplicativo desktop. Recomendamos a utilização na forma de serviço do Windows pelas diversas vantagens que este método possui. A principal delas é a possibilidade de auto-inicialização caso o servidor seja reiniciado inesperadamente. Para isso, basta configurar o serviço para executar automaticamente. IMPORTANTE: Não inicie o serviço agora.

RemoteServerServceAntes de iniciar o serviço precisamos configurá-lo. A primeira coisa a fazer é copiar os arquivos necessários ao servidor de aplicação. Inicialmente copie todos os arquivos da pasta ‘bin’ (ou ‘bin\Debug’ dependendo das suas configurações no Visual Studio) do projeto AgendaTelefonica.BO para a pasta de instalação do RemoteServer.NET. Agora copie também para essa mesma pasta o arquivo ‘FirebirdSql.Data.FirebirdClient.dll’. Voce pode encontrá-lo na pasta de instalação do RSClass – Geração de Classes. A segunda coisa a fazer é alterar o arquivo ‘RemoteServerService.exe.config’. Abra o arquivo com seu editor de texto preferido (ou o próprio Visual Studio) e altere a linha a seguir

<wellknown mode="SingleCall" type="TesteServer.MyClass, TesteServer" objectUri="TesteServer"/>

para

<wellknown mode="SingleCall" type="AgendaTelefonica.BO.BOFactory, AgendaTelefonica.BO" objectUri="AgendaTelefonica.BO"/>

Esta mudança define no servidor qual a classe que será utilizada para receber requisições da camada de apresentação para a camada de regras de negócio. Já vimos que todas as chamadas para essa camada deverá ser feita através do BOFactory. Por isso a configuração foi feita utilizando essa classe. Ainda no arquivo, a porta pela qual o servidor irá receber chamadas TCP será a ‘1234’ (poderia ser outra) e foi definida na linha do arquivo como mostrado abaixo.

<channel port="1234" ref="tcp"/>

Essas e outras informações são configurações necessárias ao .NET Remoting no qual se baseia nosso servidor de aplicação. É interessante conhecer bem a sua sintaxe e, para saber mais, pesquise detalhes na internet. Não iremos discutir esse assunto por estar fora de escopo deste tutorial.

Seguindo em frente, ainda precisamos configurar a camada de acesso a dados (DAO’s) e a persistência (NHIbernate). Logo após a tag <configuration> ainda no arquivo ‘RemoteServerService.exe.config’, Acrescente as linhas abaixo. Note que a parte em vermelho corresponde a string de conexão do banco de dados e deve ser modificada. No arquivo ‘Web.Config’ da aplicação web possui a string de conexão gerada pelo RSClass – Geração de Classes. Voce pode copiar de lá e substituir aqui.

<configSections>
<section name="hibernate-configuration" type="NHibernate.Cfg.ConfigurationSectionHandler, NHibernate"/>
</configSections>
<appSettings>
<add key="assembly" value="AgendaTelefonica.OR"/>
</appSettings>
<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
<session-factory>
<property name="connection.isolation">ReadCommitted</property>
<property name="show_sql">true</property>
<property name="connection.provider">NHibernate.Connection.DriverConnectionProvider</property>
<property name="dialect">NHibernate.Dialect.FirebirdDialect</property>
<property name="connection.driver_class">NHibernate.Driver.FirebirdClientDriver</property>
<property name="connection.connection_string">Server=localhost;Database=C:\Sistemas\Visual Studio\Projeto AgendaTelefonica\DB\AGENDATELEFONICA_DB.FDB;User=sysdba;Password=masterkey</property>
</session-factory>
</hibernate-configuration>

E assim, as configurações do servidor da aplicação foram feitas e agora já podemos iniciar o serviço. O próximo passo é configurar a aplicação web para utilizar o nosso servidor de aplicação.

Abra o RSClass – Geração de Classes no projeto da Agenda Telefônica e antes de conectar marque a opção ‘BO com servidor de aplicação (RemoteServer.NET)‘. Clique em ‘Conectar‘ e gere novamente a classe ‘BOAccess‘. O novo arquivo ‘BOAccess.cs‘ foi modificado e agora irá utilizar o servidor de aplicação para acessar as regras de negócio. Ele pode ser encontrado na pasta ‘Diversos‘ da aplicação Web. O arquivo ‘Web.config‘ também precisa ser alterado. Na sessão ‘<appSetting>‘ acrescente a seguinte linha:

<add key="remote_server_bo" value="tcp://localhost:1234/agendatelefonica.bo" />

E agora a última modificação no projeto: remova a referência ‘AgendaTelefonica.BO‘ da apliação web. Como a aplicação está utilizando a regra de negócio presente em nosso servidor de aplicação então não é mais necessário ter essa referência. Execute novamente a aplicação. O leitor pode se perguntar uma coisa: porque, mesmo removendo essa referência do projeto, não dá erro de compilação?! A resposta é: por causa das Interfaces. No paradigma da orientação a objetos as Interfaces promovem o desacoplamento. Por exemplo, voce pode desenvolver sua aplicação apenas sabendo a assinatura dos métodos da classe, ou seja, voce pode desenvolver sem saber ou ter a implementação da classe propriamente dita. Com isso é possível fazer com que um desenvolvedor trabalhe nas regras de negócio enquanto outro trabalha na camada de apresentação. Basta apenas que definam juntos as Interfaces das classes. Na camada de regra de negócio as Interfaces irão fazer parte da definição das classes. Na camada de apresentação as Interfaces irão ser utilizadas para referenciar os métodos das classes da camada de negócio.

Mas voltando a nossa aplicação, voce pode instalar o servidor de aplicação em outra máquina da rede utilizando os mesmos passos mostrados anteriormente. Porém, no web.config da aplicação no servidor web voce deverá informar o IP desse servidor de aplicação para que as requisições sejam feitas corretamente.

<add key="remote_server_bo" value="tcp://ip_do_servidor:1234/agendatelefonica.bo" />

Na pasta de instalação do RSClass – Gerador de Classes voce pode encontrar os arquivos deste tutorial gerados até aqui (PARTE VII).

Desenvolver sistema é bastante trabalhoso. Mas este desgaste pode ser bem diminuído. Padrões de projetos, geradores de código, pesquisas e toda a engenharia de software podem ser aliados nessa tarefa de desenvolver bons programas.

Não iremos desenvolver as regras de negócio da aplicação modelada na introdução desta série de artigos e deixaremos a cargo do leitor. Para auxiliar nessa tarefa sugerimos adquirir um dos nossos projetos na área de Sistemas c/ Fontes. Além de auxiliar no seu estudo, você estará contribuindo e incentivando a manutenção desse nosso trabalho e pesquisas.

Desde já agradeço a todos e até os próximos.

Anúncios