Organizando NameSpaces
Com a introdução do .NET Framework, novos desafios surgiram para nós desenvolvedores Delphi, entre eles posso citar o aprendizado das classes que compõem o framework, o conhecimento de como o framework trabalha para que possamos utiliza-lo de forma otimizada. Mas o mais simples, mas que pode causar dores de cabeça, é como organizar ou criar uma estrutura de namespaces. Quem aqui nunca sentiu dificuldade em nomear métodos, classes ou até mesmo variáveis?
Não existe uma regra que diz: “É assim”. Em um software orientado a objetos é uma boa, e porque não dizer obrigatória, prática dividir a arquitetura do software em camadas, ou subsistemas. Aplicando isso aos namespaces podemos dizer que devemos organizá-los de tal forma que represente essa separação.
Quero apresentar neste artigo uma das possíveis formas para se organizar namespaces, não é uma regra, é apenas uma prática.
Apresentando o Cenário
Digamos que trabalhamos em uma empresa chamada ClubeDelphi e nossa empresa possui um software chamado Sample (exemplo em inglês) que está divido na seguintes camadas:
· Interface com usuário (Web e Winforms)
· Camada de serviço que utiliza padrão façade
· Regras de negócio
· Acesso a dados
Para que não haja conflitos em namespaces existentes ou futuros, é recomendado que o namespace inicie sempre com o nome da empresa seguido pelo nome da aplicação a qual ele pertence. Portanto para nossa empresa e software nossos namespaces iniciam com:
ClubeDelphi.Sample
Seguindo o modelo de organizar por camadas temos a seguinte hierarquia:
· Interface com usuário
ClubeDelphi.Sample.UI
.Web: contém elementos de interface com usuários para Web
.Pages : contém as páginas
.WebControls: contém controles personalizados
.Windows: contém elementos de interface com usuários para Windows
.Forms: contém os formulários do projeto
.Controls: contém os controles personalizados
· Camada de Serviço
ClubeDelphi.Sample.Services
.Facade: contém os métodos façade para acesso às classes de negócio
.Security: responsável por verificar permissões de usuários aos objetos
· Regras de Negócio
ClubeDelphi.Sample.Business
.Classes: Contém as classes envolvidas no negócio, como Clientes, Fornecedores
.Rules: Contém regras, validações das operações de negócios
· Acesso a dados
ClubeDelphi.Sample.DataAccess
.DataSets: Contém os DataSet utilizados
.Helpers: Contém classes auxiliadoras para acesso aos dados
Constantes e Exceções
Agora você pode perguntar, onde coloco minhas exceções personalizadas, minhas constantes? Eu particularmente prefiro coloca-las no grupo a que se dizem respeito. Por exemplo, se tenho constantes e exceções para lidar com páginas web, eu as colocariam respectivamente em:
ClubeDelphi.Sample.Web.Pages.Consts
ClubeDelphi.Sample.Web.Pages.Exceptions
Caso existam rotinas, ou constantes ou exceções ou que mais que seja que devem ser vistas por toda aplicação, podemos definir então um o seguinte namespace e inseri-las nele:
ClubeDelphi.Sample.Globals
Frameworks personalizados
Se a equipe de sua empresa possui o bom hábito de criar rotinas comuns que serão reutilizadas com todos os projetos da empresa, como por exemplo um conjunto de classes personalizado por vocês para acesso a arquivos, ou para tratamento de strings, ou geração de sentenças SQL poderíamos ter os seguintes namespaces particularmente:
ClubeDelphi.Frameworks.FileAccessHelpers
ClubeDelphi.Frameworks.StringHelpers
ClubeDelphi.Frameworks.SQLHelpers
Veja que o namespace representa o nível de reusabilidade desses frameworks, isso facilita a leitura de código e entendimento da organização do mesmo.
Conclusões
Foi apresentada uma sugestão de como organizar seu código, facilitando a visão organizacional do mesmo. Vale lembrar que esta sugestão de organização de código não é restrita apenas ao Delphi2005 ou Delphi2006 em desenvolvimento para .NET, a partir do Delphi 7 é permitido utilizar as chamadas dotted units, ou units pontuadas. Por exemplo:
ClubeDelphi.Frameworks.StringHelpers.pas
ClubeDelphi.Frameworks.SQLHelpers.pas
Abraço e até a próxima!
