• Nenhum resultado encontrado

Terceiro Incremento: Conexão entre Programa e Banco de Dados

Equação 4: Preço de Venda pelo BDI Percentual

3 DESENVOLVIMENTO DE SOFTWARE DE PROGRAMAÇÃO

3.1 MODELO DE PROCESSO INCREMENTAL

3.1.3 Terceiro Incremento: Conexão entre Programa e Banco de Dados

A conexão entre programa e banco de dados se dará com a programação propriamente dita. Como apresentado no Capítulo 2 deste trabalho, a vantagem de se trabalhar com uma linguagem orientada a objetos é a de que podem ser criadas “Classes” para manipular objetos e fazer com que, caso seja necessário, se comuniquem com um ou mais Bancos de Dados.

Este trabalho apresenta apenas um Banco de Dados, porém possui várias tabelas dentre dele. Para que cada uma das telas criadas no primeiro incremento seja funcional é necessário que exista uma comunicação entre esta tabela e a sua tela correspondente.

Para que esta comunicação exista, uma classe deve ser criada para abrir a comunicação com o Banco de Dados, e outra classe deve ser criada para efetivamente ter acesso as tabelas contidas no mesmo banco.

A figura 54, página 76, apresenta o “Solution Explorer” do projeto. O nome dado a solução é “Solution ‘SVR_03’”. Além do projeto também estão indicadas duas pastas importantes, a pasta “Layers” e a pasta “Layout”, além do Banco de Dados “ebudget.mdf”.

Figura 54 – Solution Explorer do Projeto Fonte: Autor (2017).

A pasta “Layout” armazena as telas construídas no primeiro incremento. Como pode ser verificado na figura 55, uma pasta denominada “Cadastros” foi criada para armazenar todas telas para que os usuários do programa possam utilizar as informações com o Banco de Dados. Como indicado na figura 55, uma classe chamada “CadastroClientes” está relacionada com a tela “CadastroClientes.cs”.

Figura 55 – Classe CadastroCliente Fonte: Autor (2017).

A classe “CadastroCliente” ainda não é funcional neste momento. Ela precisa ser programada para que cada tela e seus objetos como botões, áreas de preenchimento e de busca possam ser funcionais.

O programa Ebudget, projeto de estudo, possui mais de 60 classes, cada uma delas com dezenas de linhas de programação. Todo o código de programação, assim como a pasta do projeto com a solução e todas as telas e executáveis serão disponibilizados em CD.

Para um entendimento preliminar da estrutura da Linguagem C# no ambiente Visual Studio, a classe “CadastroClientes.cs” é usada como exemplo para localização dos principais itens.

Segundo Santos (2010), a estrutura da Linguagem C# representada na figura 56 possui:

1. Classes Externas; 2. Nome do projeto; 3. Nome da classe; e, 4. Procedimento principal.

Figura 56 – Estrutura do Código Classe CadastroCliente Fonte: Autor (2017).

As “Classes Externas” são adicionadas automaticamente quando o projeto é criado, sendo classes básicas e necessárias para que a aplicação funcione corretamente. Cada instrução da linguagem utilizada no programa contém a definição para o compilador por meio dessas classes.

O “Nome do projeto” possui o nome de quando o projeto é criado, ele vai possuir um diretório com todos os arquivos e subdiretórios.

“Nome da classe” representa o nome da classe que está sendo criada. Ela pode ser alterada a qualquer momento.

O “Procedimento principal” é o local aonde o trecho do programa ou o próprio programa se torna funcional, ou seja, aonde o código precisa ser programado.

A classe apresentada na figura 56 possui grande quantidade de linhas, por isso não será apresentada por inteiro. A figura 57 apresenta apenas as linhas finais dessa classe.

Figura 57 – Final do Código Classe CadastroCliente Fonte: Autor (2017).

A classe apresentada não possui interligação com o Banco de Dados. Para que haja comunicação, outras classes precisam ser construídas. O local aonde as classes que darão funcionalidade ao programa serão armazenadas é a pasta “Layers”.

Dentro desta pasta as classes estarão dividas em três outros diretórios: Controller, DAO, Model. conforme figura 58.

Figura 58 – Pasta Layers Fonte: Autor (2017).

A pasta Model armazenará as classes responsáveis por armazenar temporariamente as informações do programa, antes de carregar o Banco de Dados. A classe “Clientes.cs” foi criada para permitir que as informações da classe “CadastroClientes.cs” sejam armazenadas temporariamente no programa (figura 59).

Figura 59 – Pasta Model Fonte: Autor (2017).

Para que o Banco de Dados trabalhe junto com a Interface (Layout) do programa, a pasta DAO (figura 60) precisa conter classes que realizem a comunicação com o banco.

Figura 60 – Pasta DAO Fonte: Autor (2017).

A classe “BancodeDados.cs” será a responsável pela comunicação com o Banco de Dados. Essa classe será chamada por outras classes quando necessária.

A classe “ClientesDAO.cs” será a classe que usará a classe “BancodeDados.cs” para abrir comunicação com a tabela “CLIENTES” no banco de dados “ebudget.mdf” (figura 61 a 63).

Figura 61 – Classes Clientes Fonte: Autor (2017).

Figura 62 – Tabela CLIENTES no Banco de Dados Fonte: Autor (2017).

Figura 63 – Classes BancodeDados.cs e ClientesDAO.cs Fonte: Autor (2017).

Para evitar problemas de hierarquia entre as diversas classes envolvendo os clientes, uma outra classe (ClientesController.cs) foi criada para controlar a comunicação entre o Model e o Banco de Dados, que no caso do programa Ebudget foi chamado de “ebudget.mdf”.

Figura 64 – Pasta Controller Fonte: Autor (2017).

Em geral:

1. Classes Controller: Faz a comunicação entre o Model (aonde os parâmetros são passados) e o Banco de Dados;

2. Model: Chamado de objeto, onde as informações da tela estão disponíveis para eventual acesso pelo Banco de Dados;

3. Classes DAO: São as classes responsáveis pelas transações com o Banco de Dados, inserindo, atualizando, deletando e/ou consultando informações.

Após a criação de todas as classes nas pastas Layout, Layers (Model, DAO, Controller), considerando o banco de dados funcional, o programa poderá finalmente

ser utilizado no Visual Studio. Para realizar os testes, basta clicar no botão “Start” com a opção “Debug” selecionada a sua direita (figura 65).

Figura 65 – Start Debug Fonte: Autor (2017).

Após o clique em “Start” o programa será executado (figura 66)

Figura 66 – Executando o Debug Fonte: Autor (2017).

Como pode ser observado na figura 66, a tela de login é semelhante a tela de login da figura 15, na página 58. Assim como a tela de login, a tela de inicial (figura 16) e as demais telas são as mesmas criadas no primeiro incremento deste estudo.

Documentos relacionados