Casion
Análise e desenvolvimento de software
Dicas e truques: Organização dos namespaces
Dec 26th
Maneiras simples de manter seu código fonte e organizado
Este post é uma continuação do meu anterior, Organização de um projeto. Apesar dos assuntos não terem uma ligação direta, utilizarei o exemplo criado no primeiro artigo. Então, sugiro sua leitura antes desta.
![cérebro[1]](http://casion.com.br/img/16216a2328fb_131AB/crebro1.jpg "cérebro[1]")
O cérebro humano é capaz de assimilar muitos conhecimentos através de semelhanças. Uma vez que você aprendeu a dirigir um carro, você será capaz de dirigir do mais simples até uma poderosa Ferrari (ou pelo menos na teoria), pois todos se baseiam no mesmo conceito: volante, pedais, acelerador, embreagem, retrovisores etc. Tudo isso porque foi difinido um padrão de como deve ser um carro.
Olhe ao seu redor. Em todos os lugares veremos padrões. Você vê um interruptor na parede, e mesmo sem nunca tê-lo apertado, sabe que ele é responsável por acender ou apagar alguma lâmpada. Mas se o mesmo estiver na rua, provavelmente será a campainha de algum lugar. Você aprendeu isso e aposto que nem se deu conta.
Agora chega de teorias sobre o conhecimento humano, e vamos falar de software. A primeira dica desse post é: adote padrões.
Sim, padrões. Quanto mais padronizado a sua forma de escrever códigos, algoritmos, organizar arquivos, nomes de campos, proprieades e tantas outras coisas, mais simples será de entender o seu trabalho.
Vamos voltar a usar o meu projeto myERP. Focaremos mais na estrutura do projeto myERP.BLL do que nos demais.
Tivemos uma reunião com o cliente. Definimos que nosso ERP terá os módulos de Cadastro, Financeiro e RH. Obrigatoriamente, teremos um módulo de Acesso, para definr logins, senhas e direitos de acesso por usuário.
Lembre-se: a intenção aqui não é definir o melhor software de ERP do mundo. É simplesmente criar uma maneira de organizar todas as classes que vamos gerar.
No nosso projeto, criaremos “pastas” para cada módulo do nosso ERP. Para quem não sabe, essas pastas serão representadas como divisões no namespace do nosso projeto.
Na minha BLL, criarei classes chamadas de Repositórios. Eu defini que toda a interface visual se comunicará com as regras de negócio somente através dessas classes. Ou seja, as demais classes do meu projeto BLL serão usadas internamente.
No meu projeto, todos os repositórios terão métodos para Incluir, Alterar e Remover itens. Cada repositório poderá ter métodos específicos. Por exemplo, o repositório de usuários do sistema podemos ter o método bool Login (string loginName, string password).
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using myERP.Types;
namespace myERP.BLL.Acesso
{
public class RepositorioUsuario
{
public bool Login(string loginName, string password);
public bool Incluir(cUsuario novoUsuario);
public bool Alterar(cUsuario Usuario);
public bool Remover(cUsuario Usuario);
}
}
Obviamente, esses repositórios podem herdar sua estrutura de uma classe abstrata. Mas a intenção desse artigo ainda não é mostrar exemplos em código, mas sim dar uma visão sobre alguns conceitos.
Para auxiliar na definição de quais classes utilizar, sugiro o estudo da técnica SRP – Single Responsibility Principle (Princípio da Responsabilidade Única). Esta técnica consiste em “perguntar” a si mesmo se a classe possui apenas um motivo para mudar. Existem ótimos blogs sobre desenvolvimento descrevendo essa técnica, eu recomendo este.
Com cada repositório devidamente configurado, podemos começar a escrever nossos testes, antes mesmo de começar a desenvolver a interface visual.
No meu próximo post falarei um pouco sobre este conceito de teste, como desenvolver e executá-lo, com uma visão superficial. Daí então este blog mergulhará em conceitos um pouco mais avançados, detalhando alguns processos.
até breve!
PH
Dicas e truques: Organização de um projeto
Dec 25th
Maneiras fáceis e eficientes de organizar os arquivos dos seus projetos
Importante: esta é a minha opinião, minha forma de trabalhar. Isto não quer dizer que seja a melhor forma, a solução para todos os problemas ou que existam outras formas melhores. Esta dica / solução é a que melhor me atende em certos casos.
É muito comum quando começamos a trabalhar em um novo projeto em nos preocuparmos apenas com os prazos e metas iniciais, ter toda a tecnologia em funcionamento e o cliente satisfeito. Porém é muito comum que nossos pequenos projetos cresçam desorganizadamente com o passar do tempo, nossa pasta de projeto cada vez mais se torna um amontoado de arquivos com nomes incompreensíveis, aumentando a dificuldade em se dar manutenção no projeto.
Bom, como primeiro post do blog, resolvi citar algumas técnicas que eu uso no meu dia a dia para manter meus projetos organizados de maneira eficiente. Neste exemplo, vou utilizar o Visual Studio 2010. Porém estas dicas são válidas para qualquer projeto que utilize uma estrutura parecida, tanto em .Net quanto Java.
Neste projeto, levarei em consideração alguns Design Patterns e conceitos meus. Não entrarei em detalhes por não ser este o objetivo desse Post.
Vamos lá: Que tal começarmos definindo um projeto? Fizemos todas as reuniões com o cliente e definimos que vamos desenvolver um ERP com uma interface bem rica para Windows e a possibilidade de se fazer algumas consultas e processos via uma Interface Web.
Vamos dar o nome para nosso projeto. Vou chamá-lo de myERP (não sei se este software já existe. Tomei o nome apenas como exemplo para facilitar no entendimento de vocês)
Pela conversa com o cliente, descobrimos que serão necessários duas interfaces para o mesmo sistema. Então vamos assumir que o desenvolvimento em camadas será mais fácil para trabalhar nesse projeto.
Nomenclatura dos projetos
Eu gosto de definir cada projeto com a nomenclatura <nome_do_sistema>.<dominio>. Entenda domínio como o limite da camada. O nome da Solution normalmente fica como <nome_do_sistema>.<visualização>. Entenda visualização como o limite de funcionalidades.
Exemplo:
Solution myERP.Windows – Compreende tudo o que é necessário para o funcionamento do sistema no ambiente Windows. Ao compilar esta solution, tenho o sistema pronto para ser usado.
myERP.WIN – Camada GUI, compreende toda a programação visual (forms, sequências de tela, interfaces gráficas, relatórios etc)
myERP.BLL – Camada de negócios, compreende todas as funcionalidades do sistema. Imagine o sistema inteiro funcionando, sem interface gráfica
myERP.DAL – Camada de banco de dados. Faz a comunicação entre seus objetos com as tabelas do banco de dados
myERP.Types – Opa! Types? Neste projeto eu separo todas as classes usadas por todos os projetos. Todas as camadas trocam objetos desses tipos. Dessa forma não é necessário criar novos parâmetros em várias atualizações que faremos nos nossos projetos.
Ainda falando desse projeto Types, imagine que seu cliente solicite uma nova informação não obrigatória no cadastro de usuários do sistema. Você precisa apenas adicionar essa informação no seu projeto Types e configurar essa comunicação na camada DAL. Ou seja, este campo novo passa a funcionar no seu sistema, mesmo sem uma implementação na camada visual. E quando fizer a atualização na camada visual, não será necessário nenhuma alteração na sua BLL. Simples, não acha?
Ok, mas e agora? ainda temos um site para desenvolver.
A Solution do site usará os mesmos projetos da nossa Solution Windows.
Solution myERP.WebSite– Compreende tudo o que é necessário para o funcionamento do sistema no ambiente Site. Ao compilar esta solution, tenho o sistema pronto para ser usado e registrado num IIS.
myERP.WEB – Camada GUI, compreende toda a programação das páginas.
myERP.BLL, myERP.DAL, myERP.Types – Opa! Estes projetos são os mesmos da outra solução. Entende agora a facilidade em trabalhar em camadas? podemos ter duas ou mais interfaces para o mesmo sistema sem a necessidade de reprogramar as mesmas regras de negócio, criar um novo modelo de banco e coisas do gênero.
Veja como fica o gráfico de dependências do meu projeto:
Com esta estrutura, fica muito fácil implementar um componente ORM (Ex Microsoft Entity Framework, nHibernate ) apenas na camada DAL, utilizando as classes da camada Types.
Também fica fácil criar novas interfaces, como Webservices, WCFs, ter o mesmo sistema funcionando em banco de dados diferentes, executar testes e encontrar bugs.
Veja como ficou organizada a pasta do meu projeto.
Bom, é isso 
Espero que tenha sido útil. No próximo post darei algumas dicas em como organizar o seu Assembly em namespaces eficientes, com uma pequena base em DDD.
até a próxima!
