Boas Práticas com C# e .NET Framework – Revista .net Magazine 91 - Parte 2

Para um desenvolvedor de sistemas, apenas conhecer detalhes do ambiente onde os programas são feitos é pouco. A linguagem, a estrutura dos dados e a maneira como as diversas partes são conectadas fazem parte do conhecimento inicial. Faz parte do processo de criação escolher a melhor maneira de criar os programas para que seja mais rápida a sua entrega e principalmente suas futuras manutenções.

Com relação à manutenção, este é um aspecto que muitas vezes é negligenciado por boa parte dos profissionais que gostariam que seus produtos fossem como caixas seladas e nenhuma alteração fosse necessária. Existem dois extremos que precisam ser evitados: primeiramente, o programa não pode ser fechado para extensões ou modificações a ponto que se torne impossível sua evolução, por outro, não deve ser tão flexível a ponto de se perder seu núcleo fundamental, ou seja, onde as principais regras são mantidas.

Há alguns anos vem sendo consolidada uma prática que oferece uma alternativa para flexibilização dos softwares comerciais. Esta prática é conhecida como sistema multicamadas (ou, no termo em inglês, multi-tier).

A principal ideia por trás desta prática é separar o software em partes lógicas sendo que cada uma responde por uma parte. As mais comuns: persistência e estrutura dos dados, regras de negócio e camada de apresentação.

Antes de tudo é válido levar em consideração que as práticas apresentadas aqui se destinam ao desenvolvimento de software em camadas partindo do zero, sem usar nenhum conjunto de práticas ou template de projetos como, por exemplo, MVC ou MVVM. Estes são padrões muito bem documentados e o ponto de partida para desenvolver em camadas respectivamente, aplicações Web com o ASP.NET MVC e desktop usando o WPF.

 Separando as responsabilidades

Uma maneira bem simples e até mesmo mais direta de se implementar programas em camadas usando o .NET Framework é dividir o desenvolvimento do software em vários projetos do Visual Studio.

Dentro desta proposta em um projeto ou conjunto destes se tem uma class library responsável por fornecer as classes contendo os dados e eventualmente, funcionalidades para realizar sua persistência em bancos de dados ou outros meios de armazenamento. Outro projeto, que também pode ser uma class library ou um serviço (WCF seria uma escolha natural), cuidaria da validação dos dados e outras regras de negócio. Este projeto pode realizar cálculos específicos para cada caso e pode haver um personalizado para cada tipo de cliente, por exemplo.

Finalmente se tem a camada de apresentação onde é desenvolvida a interface com o usuário. Atualmente há um número muito grande de opções de interface dentro das aplicações do Framework:

• Windows Forms e WPF para aplicações baseadas em Desktop;
• ASP.NET, Silverlight, HTML e AJAX para a Web;
• Interfaces para dispositivos móveis como o Silverlight para o Windows Phone 7.

Uma das motivações para fazer esta separação, que pode ser representada de forma simplificada na Figura 1, é que seja possível substituir qualquer uma das partes sem que o software pare de funcionar. Para aqueles que já estão acostumados com o assunto, existe um termo chamado baixo acoplamento que pode ser usado nesta situação.

Acoplamento define o nível de dependência existente entre as partes de um software como as classes de dados, bancos de dados e outras partes como a interface. Quanto mais independente uma parte for da outra, menor será o grau de acoplamento.

Não existe um padrão para se usar esta prática, porém, quanto menor o grau de acoplamento em um produto de software, melhor será para este evoluir e adaptar-se a novas situações e requisitos.

Considere duas situações para avaliar o nível de acoplamento de seu software. Pense em um software de emissão de notas fiscais. Embora a lei sobre comercialização de produtos e serviços estabeleça as regras, existem particularidades para cada ramo de empresa com relação a cálculo dos valores dos impostos da nota e também sobre as informações que são impressas.

Quanto mais fácil for para adaptar esta nota fiscal às diversas exigências para cada ramo de negócio, menor será o acoplamento do software.

Se este exemplo pareceu forçado (considerando o desenvolvimento de software no Brasil, não é, pode acreditar), pense em outra hipótese: substituir a interface com o usuário para Web ou WPF ou ainda, e talvez o pior de todos, substituir o banco de dados onde é feito o armazenamento.

Camada para dados e persistência

Não existe o sistema de banco de dados perfeito para todos os casos. Cada projeto pede uma solução que envolve não apenas aspectos técnicos como econômicos e de políticas de cada empresa.

Para determinadas equipes de desenvolvimento, é possível fazer com que o seu usuário adote o banco de dados de sua preferência, mas, há casos em que um mesmo software precisará ser capaz de usar diversos tipos de bancos.

Isto pode representar problemas maiores que precisam ser resolvidos. Uma forma interessante de se resolver o problema com o desenvolvimento feito com o .NET Framework é dividir o projeto de dados em duas partes.

Na primeira, basicamente seriam definidas as classes e suas estruturas de dados. Considere por exemplo um projeto para armazenamento de dados de publicações. A classe com a estrutura de dados pode ser conferida na Listagem 1.

Listagem 1. Classe Publicação

using System;

namespace Dados

{

  public class Publicacao

  {

    public Int32 Id { get; set; }

    public String Titulo { get; set; }

    "