Conceitos de Programação e Arquitectura de Software (I)

Introdução

Hoje em dia a complexidade dos sistemas de software, exige a sua concepção e desenvolvimento obedeçam a regras criteriosas, à utilização das tecnologias e técnicas mais adequadas e à aplicação de boas práticas.

Um dos pontos chave para atingir o objectivo de criar bons sistemas é a Arquitectura de Software.

Mas o que é isso da Arquitectura de Software? E as técnicas? E as boas práticas?

O objectivo desta série de artigos é dar resposta a estas e muito mais perguntas, sistematizando, de forma clara e sucinta, um conjunto de conceitos base sobre arquitectura e desenvolvimento de software, para novos programadores.

O artigo foca-se na Programação Orientada a Objectos (POO) e os exemplos apresentados foram desenvolvidos na linguagem C#, da plataforma Microsoft .NET, mas os conceitos são aplicáveis a qualquer outra tecnologia ou linguagem.

Conteúdo

• 1. Arquitectura de Software
  • 1.1. O que é a Arquitectura de Software?
  • 1.2. Porque é importante a Arquitectura de Software?
  • 1.3. Quais os objectivos da Arquitectura de Software?
  • 1.4. Arquitecturas por camadas
    • 1.4.1. O que é a arquitectura de 2 camadas (2-tier)?
    • 1.4.2. O que é a arquitectura de 3 camadas (3-tier)?
    • 1.4.3. O que é a Data Access Layer (DAL)?
    • 1.4.4. O que é a Business Logic Layer (BLL ou BL)?
    • 1.4.5. O que é a Presentation Layer (PL ou UI)?
  • 1.5. Algumas Arquitecturas populares
    • 1.5.1. O que é a Arquitectura MVC?
    • 1.5.2. O que é a Arquitectura SOA?
• Referências

1. Arquitectura de Software

1.1. O que é a Arquitectura de Software?

A Arquitectura de Software corresponde ao processo de de criar uma solução estruturada que responda a todos os requisitos técnicos e operacionais do sistema. Consiste na estrutura, ou estruturas de alto nível do sistema, às regras, procedimentos heurísticos e padrões para criar tais estruturas e à documentação dessas estruturas.

“As estruturas do sistema compreendem elementos de software, as propriedades desses elementos, visíveis do exterior e as relações entre eles. A arquitectura preocupa-se com a parte pública dos interfaces, os detalhes privados dos elementos de software – aqueles que dizem respeito apenas à implementação – não são arquitecturais.”
-- Bass, Clements e Kazman
”Software Arquitecture in Practice” (3ª edição)

A arquitectura de software NÃO É um conjunto ou uma pilha de tecnologias (entenda-se aqui tecnologias como as ferramentas, técnicas e APIs usadas para construir o sistema).

No mundo da programação, quando alguém pergunta como vamos arquitectar uma dada aplicação, muitas vezes dizemos, por exemplo, que vamos construir um sistema baseado em “ASP.NET MVC 4, com uma camada de serviços WCF, em cima duma framework e os dados são guardados numa BD do SQL Server”. Isto é uma pilha de tecnologias, mas não nos descreve como vai ser o sistema. É como se perguntássemos qual a arquitectura de um edifício e nos dissessem que é feito com tijolos, cimento e que vão ser usadas betoneiras e colheres de pedreiro para o construir.

1.2. Porque é importante a Arquitectura de Software?

A arquitectura de um sistema define as grandes decisões a serem tomadas.

Primeiro temos que identificar os requisitos do sistema, que pode ser de diferentes tipos.

Como podemos ver, nem todos os requisitos são compatíveis entre si. Então, temos que tomar decisões que garantam que o sistema está equilibrado - que corresponde aos objectivos para que foi desenhado, dentro do ambiente onde vai ser executado.

Em resumo, a arquitectura de software é importante porque:

• Controla a complexidade
• Força a aplicação das melhores práticas
• Dá consistência e uniformidade
• Aumenta a previsibilidade
• Permite a reutilização

1.3. Quais os objectivos da Arquitectura de Software?

O principal objetivo da arquitectura de software é identificar os requisitos que afectam a estrutura do sistema. A arquitectura procura construir uma ponte entre os requisitos de negócio e os requisitos técnicos, através da compreensão dos Casos de Uso e da definição de formas de implementar esses casos de uso no software.

Lembrar que a arquitectura deve:

• Expor a estrutura do sistema, mas esconder os detalhes de implementação
• Identificar todos os casos de utilização e cenários
• Tentar dar resposta aos requisitos de vários intervenientes (stakeholders)
• Tratar dos requisitos funcionais e de qualidade

1.4. Arquitecturas por camadas

1.4.1. O que é a arquitectura de 2 camadas (2-tier)?

A arquitectura de 2 camadas refere-se ao modelo cliente/servidor, termo que começou a ser usado na década de 1980, referindo-se a computadores pessoais ligados em rede. O modelo cliente/servidor real começou a ganhar aceitação no final de 1980 e mais tarde foi adoptado para a programação Web.

Actualmente, na utilização da arquitectura de 2 camadas, os interfaces do utilizador (UI) (p.ex. todas as páginas Web, numa aplicação para Internet) são executados no cliente e a Base de Dados (BD) é armazenada no servidor. A lógica da aplicação pode ser executada no cliente ou no servidor. Portanto, neste caso, o UI vai aceder diretamente à BD. Os clientes também podem ser motores de processamento (e não de interface), que fornecem soluções para outros sistemas remotos ou locais.

Em qualquer dos casos, hoje em dia, o modelo de 2 camadas é preterido em relação ao modelo de 3 camadas. A vantagem de um sistema de 2 camadas é a sua simplicidade, mas a simplicidade tem o custo da escalabilidade. A arquitectura de 3 camadas (mais recente) introduz uma camada intermédia, para a lógica da aplicação.

1.4.2. O que é a arquitectura de 3 camadas (3-tier)?

A arquitetura de 3 camadas surgiu na década de 1990 com o intuito de superar as limitações da arquitetura de 2 camadas. Esta arquitectura tem sido intensivamente adoptada e aperfeiçoada pelos modernos projectistas e programadores de sistemas Web.

O modelo de 3 camadas é uma arquitetura cliente/servidor em que o UI, a lógica funcional, o armazenamento de dados e o acesso aos dados são desenvolvidos e mantidos como módulos independentes (algumas vezes até em plataformas distintas). O termo "três camadas" ou "três níveis" (3-layer), bem como o conceito de arquitecturas multi-camada, parece ter sido originado a partir do Software Rational.

A arquitetura de 3 camadas, classicamente, tem os seguintes níveis:

• Camada de apresentação ou de servidor Web: Interface do Utilizador, que exibe os dados para ou aceita inputs do utilizador (ver detalhes abaixo).
• Camada de Lógica de Negócio/Aplicação ou Servidor Aplicacional: Validação e aceitação dos dados antes de guardar na BD, processamentos, cálculos e todas as outras operações específicas do negócio/aplicação (ver detalhes abaixo).
• Camada de Dados ou Servidor BD: Simples operações de leitura e escrita de dados na BD ou em qualquer outro sistema de armazenamento (ver detalhes abaixo).

1.4.3. O que é a Data Access Layer (DAL)?

A Camada de Acesso a Dados (DAL) consiste principalmente num conjunto simples de código que efectua as interações básicas com a BD ou qualquer outro dispositivo de armazenamento de dados. Estas funcionalidades são muitas vezes referidos como CRUD (Create, Retrieve, Update, Delete).

A DAL deve ser genérica, simples, rápida e eficiente. Não deve incluir lógica de negócio/aplicação complexa. Muitos sistema têm longas e complexas Stored Procedures (SP), que são executadas para uma simples operação de leitura de dados. Estas SP contém, muitas vezes, lógica de negócio, lógica da aplicação e lógica de UI também. Se uma SP estiver a ficar muito longa, isso é sinal de que está a colocar a lógica de negócio na DAL.

1.4.4. O que é a Business Logic Layer (BLL ou BL)?

Ao lermos a imensa documentação disponível sobre este tema, percebemos que nem todos os autores concordam com o que é a Camada de Lógica de Negócio (BL). Em muitos casos é apenas uma ponte entre a Camada de Apresentação e a Camada de Dados, sem qualquer função adicional que não seja passar dados de uma lado para o outro. No entanto, nada nos impede de alterar a abordagem a este tipo de BL. Mas a mudança deve ser feita como e quando se sentir confortável de que o método a aplicar é flexível o suficiente para suportar o crescimento do sistema. Existem muitas maneiras excelentes de implementar a BL, mas tenha cuidado ao selecioná-las, pois podem complicar em excesso um sistema simples. É um equilíbrio que é preciso encontrar com base na sua experiência.

Como recomendação geral, deve decidir como mapear os dados das tabelas para Entidades de Negócio (classes) correctamente definidas. As entidades de negócio devem levar em consideração os vários tipos de requisitos e funcionamento do sistema. Pode-se usar uma abordagem de definir uma entidade separada para cada tabela da BD (a maioria dos ORMs levam a isto), mas recomenda-se a criação de entidades que permitam encapsular as exigências funcionais e de UI da aplicação, que podem ser autónomas ou, por exemplo, agregar várias entidades relacionadas com as tabelas da BD.

1.4.5. O que é a Presentation Layer (PL ou UI)?

A Camada de Apresentação ou Interface com o Utilizador (UI), como o nome indica, interage directamente com o utilizador. Tipicamente é constituída por um ambiente gráfico composto por variados objectos (controlos) que permitem ao utilizador interagir com o sistema, quer através da introdução e visualização de dados, quer através da realização de acções e introdução de comandos.

1.5. Algumas Arquitecturas populares

1.5.1. O que é a Arquitectura MVC?

A arquitetura Model-View-Controller (MVC) separa a modelagem do domínio, a apresentação e as ações baseadas nos inputs do utilizador (lógica de apresentação) em três classes distintas.

Infelizmente, a popularidade deste modelo resultou em alguns usos defeituosos. Cada tecnologia (Java, ASP.NET, etc.) definiu-o da sua própria maneira, fazendo com que seja difícil de entender. Em particular, o termo "controlador" tem sido usado para significar coisas diferentes em contextos diferentes. As definições abaixo estão o mais próximo possível da tecnologia ASP.NET MVC.

• Model: conjunto de classes que criam um modelo do sistema, usado para apresentar os dados ao utilizador. Podemos ter entidades de negócio, coleções, DataSets, etc.
• View: ficheiro de página Web (HTML, Javascript) que se encarrega de implementar o UI.
• Controller: classe que recebe os pedidos e eventos despoletados pelas acções do utilizador na View.

Num sistema distribuído de n camadas, a arquitetura MVC tem o papel vital de organizar a Camada de Apresentação.

Recomenda-se a consulta do artigo “ASP.NET MVC vs ASP.NET Web Forms – Porquê o MVC?” para maior detalhe nos conceitos desta arquitectura.

1.5.2. O que é a Arquitectura SOA?

A Arquitetura Orientada a Serviços (SOA) é  um modelo de programação em que as funcionalidades das aplicações são disponibilizadas como serviços, que utilizam o paradigma pedido/resposta para estabelecer a comunicação entre os sistemas clientes e os sistemas que implementam os serviços.

A SOA é essencialmente uma coleção de serviços, que comunicam uns com os outros e com os sistemas clientes. A comunicação pode envolver a simples passagem de dados ou pode envolver dois ou mais serviços na coordenação de alguma atividade.

Com o desenvolvimento das aplicações baseadas em Web, a utilização de Web Services tornou-se popular, tendo-se assistido a uma proliferação dos sistemas SOA. Todavia há que salientar que um serviço não é necessariamente um web service, nem tem que estar relacionado com a Web.

A SOA pode ser ainda usada como o conceito para conectar vários sistemas de prestação de serviços. Esta arquitectura tem um grande quinhão de participação no futuro do mundo das TI.

Referências

- MSDN Patterns & Practices
- Microsoft Application Architecture Guide
- Code Project - Introduction to Object Oriented Programming Concepts (OOP) and More
- Learn Visual Studio.NET - Application Architecture Fundamentals

Java 9: Última lista de funcionalidades

Introdução

O Java 8 teve o seu lançamento em Março 2014 e teremos entrado no habitual ciclo de 2 anos para um novo lançamento. O Java 9 irá, alegadamente, ser lançado em 2016.

A comunidade OpenJDK está fervilhante e acaba de ser publicada uma lista inicial de JEPs (JDK Enhancement Proposals) para a nova versão e alguns JSRs (Java Specification Requests) já estão a ser trabalhados.

Algumas das principais novidades são: o projecto Jigsaw, melhorias significativas de desempenho e algumas APIs muito aguardadas, como atualizações da Process API, JSON como parte do java.util e uma API para tratamento de dinheiro.

Para aqueles que queiram estar na crista da onda, os builds do JDK 9 já estão disponíveis aqui.

Nota: este artigo refere-se à lista de funcionalidades actualizada até 09-Set-2014

Conteúdo

• Projecto Jigsaw - código fonte modular
• Actualizações Process API
• JSON API leve
• API para divisas e dinheiro
• Melhorias de gestão de Locks
• Cache de código segmentada
• Smart Java Compilation – fase 2
• Outras novidades prováveis

Projecto Jigsaw - código fonte modular

O objetivo do Projecto Jigsaw é tornar o Java mais modular e dividir o JRE em componentes interoperáveis​​. Esta JEP é o primeiro de quatro passos para o Jigsaw e não vai alterar a estrutura actual do JRE e JDK. O objetivo deste passo é reorganizar o código fonte do JDK em módulos, melhorar o sistema de build para compilar módulos e impor limites aos módulos, em tempo de compilação. O Jigsaw foi originalmente planeado para o Java 8, mas foi adiado e redirecionado para o Java 9.

Mais sobre a JEP 201

Actualizações Process API

Até agora tem havido uma capacidade limitada para o controlo e gestão de processos do Sistema Operativo com o Java. Por ex., hoje, para fazer algo tão simples como obter o PID do processo hoje, é necessário aceder a código nativo ou usar algum tipo de workaround. Pior do que isso, será necessária uma implementação diferente para cada plataforma, de modo a garantir que está a receber o resultado certo.

O objectivo é ter algo como isto (que também suporte todos os sistemas operativos):

System.out.println ("O pid é" + Process.getCurrentPid ());

A actualização vai estender a capacidade do Java interagir com o sistema operativo: novos métodos diretos para lidar com PIDs, nomes de processos e estados, capacidade de enumerar JVMs e processos e muito mais.

Mais sobre a JEP 102

JSON API leve

Já existem alternativas disponíveis para lidar com o JSON em Java. A novidade com esta API é que o JSON se tornaria parte integrante da linguagem, seria leve e usaria os novos recursos do Java 8. Para além disso, o JSON seria disponibilizado directamente através do package java.util (Ao contrário do JSR 353, que usa um package externo ou outras alternativas).

Mais sobre a JEP 198

API para divisas e dinheiro

Após uma nova API de Data e Hora, introduzida no Java 8, a nova versão irá trazer uma nova API oficial para representar, transferir e efectuar cálculos com dinheiro e divisas. Para saber mais sobre esta API, deve consultar o projecto JavaMoney no GitHub. Eis alguns destaques:

- Dois novos tipos: Money e FastMoney:

Money amt1 = Money.of(10.1234556123456789, "USD"); // Money is a BigDecimal
FastMoney amt2 = FastMoney.of(123456789, "USD"); // FastMoney is up to 5 dec places
Money total = amt1.add(amt2);

- Formatar dinheiro de acordo com o país:

MonetaryAmountFormat germanFormat =
    MonetaryFormats.getAmountFormat(Locale.GERMANY);

System.out.println(germanFormat.format(monetaryAmount)); // 1.202,12 USD

Mais sobre o JSR 354

Melhorias de gestão de Locks

A contenção de locks é um gargalo de desempenho em muitas aplicações multi tarefa em Java. A proposta foca-se em melhorar o desempenho dos monitores de objectos Java, medido por diferentes benchmarks.

Este tipo de testes de stress puxam a JVM ao limite e tentam determinar a taxa de transferência máxima que se pode alcançar, geralmente em termos de mensagens por segundo. A ambiciosa métrica de sucesso para esta JEP é uma melhoria significativa em 22 benchmarks diferentes. Se o resultado for alcançado, estas melhorias de desempenho serão incluídas no Java 9.

Mais sobre a JEP 143

Cache de código segmentada

Outra melhoria de desempenho no Java 9 vira do compilador JIT. Quando certas áreas de código são executadas rapidamente, a JVM compila-as para código nativo e armazena-as na cache de código. Esta proposta visa segmentar a cache de código para diferentes áreas de código compilado, de forma a melhorar o desempenho do compilador.

Em vez de uma única área, a cache de código será dividida em 3:

• O código que vai ficar para sempre na memória cache (interno à JVM / código non-method)
• Tempo de vida curto (código perfilado, específico a um determinado conjunto de condições)
• Potencialmente de longa vida (código não perfilado)

Mais sobre a JEP 197

Smart Java Compilation – fase 2

A ferramenta Smart Java Compilation, ou sjavac, foi trabalhada pela primeira na JEP 139, a fim de melhorar a velocidade de construção do JDK por ter o compilador javac a ser executado em todos os núcleos. Nesta proposta, entra na Fase 2, onde será melhorada e generalizada para que possa ser usada como padrão e construir outros projetos que não apenas o JDK.

Mais sobre a JEP 199

Outras novidades prováveis

Para além das funcionalidades anteriores, que já estão a ser desenvolvidas, é provável a inclusão das seguintes:

- Cliente HTTP 2 (JEP 110)

- Projecto Kulla - REPL in Java (Read Evaluate Print Loop)

C# 6.0 (vNext) – Novas funcionalidades

Introdução

Vai-se aproximando o lançamento da nova versão da linguagem C# 6.0 (vNext) e muitos já estarão a pensar se devem adoptar a nova versão de imediato ou se devem aguardar algum tempo até ver se vale mesmo a pena.

Para dar uma ajuda, temos hoje um artigo sobre algumas das características e novas funcionalidades do C# vNext [1].

Para começar, a primeira novidade é que o novo compilador será open source. É verdade! Já se pode obter o código fonte da nova plataforma .NET Compiler Platform (“Roslyn”). A Microsoft já está a disponibilizar no CodePlex duas versões preview da nova plataforma de compiladores, uma para o Visual Studio 2013 e outra em conjunto com a versão preview também do seu novo IDE de desenvolvimento. Ambas as versões podem ser obtidas aqui.

[1] actualizadas até 10-Set-2014

Conteúdo

• Primary Constructors
• Melhorias nas Auto Properties
• Utilização de membros Static
• Expressões de declaração
• Inicialização de Índices e Dicionários
• Melhorias no tratamento de Excepções
• Conclusões
• Referências

Primary Constructors

Os primary constructors são uma abreviação sintática para a criação de um construtor que automaticamente atribui valores a variáveis privadas de instância.

Actual

public class Point
{
    private int x, y;

    public Point(int x, int y)
    {
        this.x = x;
        this.y = y;
    }
}

vNext

public class Point(int x, int y)
{
    private int x, y;
}

Melhorias nas Auto Properties

As melhorias consistem numa abreviação sintática para a criação de auto properties readonly e inicializadores.

Actual

public class Pessoa
{
    private string _nome = "Henrique";
    private string _apelido ="Rodrigues";

    public string Nome
    {
        get { return _nome; }
        set { _nome=value; }
    }

    public string Apelido
    {
        get { return _apelido; }  
    }
}

vNext

public class Pessoa
{
    public string Nome { get; set; } = "Henrique"

    public string Apelido { get; } = "Rodrigues"
}

Utilização de membros Static

Mais uma abreviação sintática, que permite utilizar os membros estáticos de uma classe (mesmo os extension methods) sem necessitar de referenciar explicitamente a classe. Basta indicá-la numa expressão using.

Actual

using System;

namespace vNext
{
    public class Program
    {
        private static void Main(string[] args)
        {
            Console.WriteLine("Hellow World");
        }
    }
}

vNext

using System.Console;

namespace vNext
{
    public class Program
    {
        static void Main(string[] args)
        {
            //usar o mtodo writeLine da classe Console
            //sem especificar o nome da classe
            WriteLine("Hellow World");
        }
    }
}

Expressões de declaração

Mais uma abreviação sintática, que permite declarar uma variável no meio duma expressão.

Actual

long id;
if (!long.TryParse(Request.QureyString["Id"], out id))
{ }

vNext

if (!long.TryParse(Request.QureyString["Id"], out long id))
{ }

Inicialização de Índices e de Dicionários

Nota: os inicializadores de índices (Index Initializers) – sinal $ - já tinham sido previamente previstos, mas não funcionam na CTP atual.

A inicialização de dicionários e outros objectos com indexadores é pouco elegante. Temos agora uma melhoria sintática que permite fazer esta inicialização duma forma mais clara.

Actual

Dictionary<string, string> antigo = new Dictionary<string, string>()
    {
        { "Portugal", "Lisboa" },
        { "Angola", "Luanda" },
        { "EUA", "Washington" }
    };

vNext

Dictionary<string, string> novo = new Dictionary<string, string>()
    {
        ["Portugal"] = "Lisboa",
        ["Angola"] = "Luanda",
        ["EUA"] = "Washington"
    };

Melhorias no tratamento de Excepções 

No tratamento de excepções, temos duas novidades:

• Filtros de excepção (Exception Filters)
• Chamadas assíncronas em blocos catch (await)

Exception Filters

try
{
    throw new Exception("Eu");
}
catch (Exception ex) if (ex.Message == "Tu")
{
    // este bloco no executa
}
catch (Exception ex) if (ex.Message == "Eu")
{
    // este bloco executa
}

await em blocos catch

try
{
    DoSomething();
}
catch (Exception)
{
    await LogService.LogAsync(ex);
}

Conclusões

Ao considerar apenas estas alterações de linguagem, percebemos que não há nada de particularmente revolucionário no C# 6.0. A grande novidade é mesmo a do compilador ser disponibilizado como open source.

Esta versão não vai revolucionar a codificação do C#, mas isso não significa que não tenham sido feitos progressos reais na eliminação de algumas ineficiências de codificação. Depois de se começar a usar estas novas funcionalidades, no dia-a-dia da programação, rapidamente se vão tornar como certas, como um dado adquirido.

Referências

http://msdn.microsoft.com/en-us/magazine/dn683793.aspx

https://roslyn.codeplex.com/

Language feature implementation status

C# feature descriptions

Microsoft ASP.NET MVC– A história até agora

Introdução

Este artigo apresenta uma visão rápida da história do ASP.NET MVC e dos recursos e funcionalidades mais importantes, introduzidos nas principais versões.

Este será o primeiro de uma série de artigos dedicados ao ASP.NET MVC. Constitui apenas uma pequena introdução, recomendando-se a consulta da vasta documentação online sobre o tema, começando pela página oficial da Microsoft, aqui.

Conteúdo

• ASP.NET MVC 1.0 (2009)
• ASP.NET MVC 2 (2010)
• ASP.NET MVC 3 (2011)
• ASP.NET MVC 4 (2012)
• ASP.NET MVC 5 (2013)
• ASP.NET MVC 5.1 (Janeiro 2014)
• ASP.NET MVC 5.2 (Julho 2014)
• Todas as versões do ASP.NET MVC

ASP.NET MVC 1.0 (2009)

A primeira versão oficial foi lançada em 2009 e trouxe todas as características fundamentais da framework, que perduram até hoje:

• Para começar, o próprio conceito de MVC, com o pipeline simplificado de processamento e separação do processamento do pedido (no Controller) e a renderização do output (na View);
• O conceito de Routing (que foi incorporado, de seguida, na Framework .NET);
• Helpers simples para renderizar tags HTML;
• Helpers para criar facilmente links e forms AJAX;
• Ligação automática de formulários submetidos (posted forms) a objetos .NET e uma espécie de validação do modelo.

Este foi um grande passo em direção a uma nova web, mas a primeira versão obrigava a demasiado desenvolvimento de infra-estrutura, por forma a ser produtivo em cenários empresariais e em grandes aplicações.

O ASP.NET MVC foi também o primeiro produto da Microsoft a ser realmente extensível. A maioria dos componentes do núcleo podiam ser estendidos ou mesmo totalmente substituídos por implementações próprias.

ASP.NET MVC 2 (2010)

No ano seguinte, foi lançada a segunda versão da framework ASP.NET MVC. O foco desta atualização foi aumentara a produtividade e  facilitar a manutenção nas grandes aplicações:

• Validação do modelo com base em atributos, tanto do lado do servidor como do lado do cliente;
• Introdução das Areas, para particionar as grandes aplicações;
• Html Templated Helpers, para renderizar automaticamente formulários de edição e páginas de exibição, com base no modelo e nos atributos aplicados sobre o mesmo;
• Controladores assíncronos;
• HTML Helpers baseados em Expressões Lambda para remover a maioria das “strings mágicas” anteriormente necessárias nos Html Helpers.

ASP.NET MVC 3 (2011)

No início de 2011, foi lançada a versão 3 do ASP.NET MVC, juntamente com uma pilha de outras ferramentas muito interessantes, como o NuGet, IIS Express e SQL Server Express.

As novidades introduzidas nesta versão foram:

• Só funciona em .NET 4;
• Novos modelos de projecto, com suporte para HTML5 e CSS3;
• Validação com unobtrusive javascript e melhor desempenho geral do javascript;
• Validação remota e melhoria geral da validação do modelo;
• Dependency Resolver incorporado;
• Razor: o novo motor para Views;
• Suporte para vários motores para Views, i.e., Web Forms, Razor ou open source;
• Melhorias do controlador como a propriedade ViewBag e tipos de ActionResults;
• Filtros globais;
• Cache de output para página parcial.

ASP.NET MVC 4 (2012)

Em 2012, é lançada a versão 4 do ASP.NET MVC com algumas novidades significativas:

• ASP.NET Web API, uma framework que simplifica a criação de serviços HTTP e serve uma grande variedade de clientes;
• Renderização adaptável e outras melhorias “look-n-feel” nos modelos padrão de projeto;
• Um modelo de projeto verdadeiramente vazio;
• Introduzido novo modelo de projecto Mobile, baseado em jQuery Mobile;
• Suporte para adicionar controladores de outras pastas de projecto;
• Controlo de tarefas para controladores assíncronos;
• Controlo de Bundling and Minification através de web.config;
• Suporte para logins  OAuth e OpenID com a biblioteca DotNetOpenAuth;
• Suporte para o Windows Azure SDK 1.6 e posteriores.

ASP.NET MVC 5 (2013)

No último trimestre de 2013 foi lançada a versão 5 do ASP.NET MVC, que passou a ser a versão standard de MVC do Visual Studio 2013. As principais novidades introduzidas foram:

• O Bootstrap substitui o modelo padrão MVC;
• ASP.NET Identity para autenticação e gestão de identificação;
• Authentication Filters para autenticação customizada de utilizador ou por provedor de autenticação de terceiros;
• É agora possível substituir filtros num método ou controlador;
• O Attribute Routing está agora integrado no MVC 5.
  

ASP.NET MVC 5.1 (Janeiro 2014)

• Melhorias no Attribute Routing;
• Suporte para tipos Enum nas Views;
• Suporte para Bootstrap nos modelos de editores;
• Validação não intrusiva para os atributos de modelo MinLengthAttribute e MaxLengthAttribute;
• Suporte para o contexto this no Unobtrusive Ajax.

ASP.NET MVC 5.2 (Julho 2014)

• Melhorias no Attribute Routing.

Todas as versões do ASP.NET MVC

A título de curiosidade lista de todas as versões do ASP.NET MVC, lançadas pela Microsoft, é a seguinte:

Data	Versão
2007-12-10	ASP.NET MVC CTP
2009-03-13	ASP.NET MVC 1.0   (download)
2009-12-06	ASP.NET MVC 2 RC
2010-02-04	ASP.NET MVC 2 RC 2
2010-03-10	ASP.NET MVC 2   (download)
2010-10-06	ASP.NET MVC 3 Beta
2010-11-09	ASP.NET MVC 3 RC
2010-12-10	ASP.NET MVC 3 RC 2
2011-01-13	ASP.NET MVC 3   (download)
2011-09-20	ASP.NET MVC 4 Developer Preview
2012-02-15	ASP.NET MVC 4 Beta
2012-05-31	ASP.NET MVC 4 RC
2012-08-15	ASP.NET MVC 4   (download)
2013-05-30	ASP.NET MVC 4 4.0.30506.0
2013-06-26	ASP.NET MVC 5 Preview
2013-08-23	ASP.NET MVC 5 RC 1 [a]
2013-10-17	ASP.NET MVC 5 [a]
2014-01-17	ASP.NET MVC 5.1 [a]
2014-02-10	ASP.NET MVC 5.1.1 [a]
2014-04-04	ASP.NET MVC 5.1.2 [a]
2014-06-22	ASP.NET MVC 5.1.3 [a]
2014-07-01	ASP.NET MVC 5.2.0 [a]

^{[a] http://www.nuget.org/packages/Microsoft.AspNet.Mvc}

Convenções de Nomenclatura

Introdução

A programação consiste em grande parte em dar nomes a coisas: classes, métodos e variáveis. Mas, conseguir criar bons nomes é bem mais difícil do que parece. Para além de respeitarem as regras da linguagem ou tecnologia em que estão a ser usados, os nomes devem ser claros para o programador que os criou, mas também para outros programadores que tenham que ler o código. É aqui que entram as Convenções de Nomenclatura (Naming Conventions).

O conceito de convenção de nomenclatura é bastante mais geral, mas, na programação, podemos dizer que consiste num conjunto de regras para a escolha da sequência de caracteres a ser usada para criar os identificadores (nomes) de classes, métodos, tipos, variáveis, ou outras entidade do código fonte e documentação. As convenções aplicam-se, normalmente, quer ao formato, quer à atribuição de significado aos nomes escolhidos.

De realçar que este é um tema controverso, pois existem variadíssimas convenções, cada uma com os seus partidários e é comum as grandes empresas criarem o seu próprio conjunto de regras, para melhor servir os seus interesses. Neste artigo vamos tentar abordar os conceitos mais importantes e analisar algumas das convenções mais populares os dias de hoje.

Conteúdo

• Benefícios da utilização de Convenções de Nomenclatura
• Conceitos e elementos mais comuns
• Convenções de Nomenclatura específicas
• Recomendações

Benefícios da utilização de Convenções de Nomenclatura

À primeira vista, as convenções de nomenclatura podem não parecer assim tão importantes. Na realidade, podemos criar código sem usar qualquer tipo de convenção e ele continuar a ser funcionalmente correcto. Então, porque devemos usar convenções de nomenclatura e porque são tão recomendadas e mesmo obrigatórias na maioria dos grandes projectos?

A utilização de convenções de nomenclatura, em oposição a deixar os programadores criar livremente os nomes e formatos dos nomes, permite que seja significativamente mais fácil a outros analistas e programadores entender entender como o sistema funciona e o que está a fazer e como corrigir ou estender o código fonte para novas necessidades de negócio.

Existem outras razões e vantagens, é claro, mas a questão da manutenção é fundamental. Quando temos que olhar para o código de outra pessoa, ou mesmo para o nosso próprio código, quando já não lhe mexemos há algum tempo, ajuda-nos ter certas expectativas sobre o que um dado identificador é e o que faz, logo à primeira vista. Se pensarmos que a maior parte do tempo de vida de uma aplicação é passado na fase de manutenção, tudo o que tornar a manutenção mais fácil, ajuda. Especialmente quando é algo tão fácil como seguir algumas convenções de nomenclatura.

Podemos enumerar mais alguns dos potenciais benefícios da utilização de convenções de nomenclatura:

• Fornecer informação adicional (metadados) sobre a utilização de um dado identificador;
• Promover a consistência dentro de uma equipa de desenvolvimento;
• Permitir o uso de ferramentas automáticas de refactoring ou find-and-replace com um potencial mínimo de erro;
• Aumentar a clareza, em casos de ambiguidade;
• Melhorar a aparência estética e profissional do produto (p.ex., por não permitir nomes excessivamente longos, cómicos, ou abreviações obscuras);
• Evitar "colisões de nomenclatura" que podem ocorrer quando o resultado do trabalho de diferentes organizações é combinado;

Vejamos um pequeno exemplo prático:

a = b * c;

embora o código acima esteja sintaticamente correcto (em Java ou C#), não é claro qual o seu objectivo ou funcionalidade.

juros = capital * taxa;

Agora tornou-se muito mais claro qual o objectivo desta linha de código.

Conceitos e elementos mais comuns

Comprimento dos identificadores
Este é um elemento sujeito a muita discussão e controvérsia, na prática, mas é fundamental em qualquer convenção de nomenclatura. Algumas regras impõem um número limite fixo de caracteres individuais permitidos para cada identificador enquanto outras especificam apenas orientações.

Algumas considerações:

• os identificadores mais curtos, podem ser tidos como mais convenientes, porque são mais fáceis de digitar;
• identificadores extremamente curtos (como o 'i' ou 'j') são muito difíceis de distinguir, ao usar ferramentas de find-and-replace;
• identificadores mais longos podem ser preferidos porque os curtos podem não codificar informação suficiente ou parecer demasiado críptica.

A preferência por identificadores mais curtos ou mais longos é uma questão ainda aberta à pesquisa. A utilização de brevidade na programação pode ser atribuída, em parte, ao seguinte:

• Os primeiros compiladores e linkers só permitiam nomes de variáveis com 6 caracteres. Mais tarde foram permitidos nomes mais longos, para permitir uma melhor compreensão humana, mas apenas os primeiros caracteres eram significativos;
• Os primeiros editores de código não possuíam autocomplete;
• Os primeiros monitores eram de baixa resolução e tinham um número limitado de caracteres por linha (p.ex. apenas 80 caracteres);
• Grande parte da ciência da computação teve origem na matemática, onde, tradicionalmente, os nomes das variáveis ​​têm apenas uma única letra.

Caixa Alta, Caixa Baixa e Números
Algumas convenções de nomenclatura definem se as letras podem aparecer em maiúsculas ou minúsculas. Outras não restringem a caixa das letras (letter casing), mas anexam uma interpretação bem definida com base em casa caso. Outras convenções especificam ainda se podem ser usados identificadores alfabéticos, numéricos ou alfanuméricos, e em caso afirmativo, em que sequência.

Identificadores multi-palavra
Uma recomendação comum, na programação, é "usar identificadores significativos". Uma única palavra pode não ser tão significativa, ou específica, como várias palavras. Consequentemente, algumas convenções de nomenclatura especificam regras para a criação de identificadores que contenham mais que uma palavra.

Como a maioria das linguagens de programação não permite a utilização de espaços em branco nos identificadores, é necessário um método de delimitação de cada palavra, que torne mais fácil de interpretar que caracteres pertencem a cada uma.

• Palavras separadas por delimitadores
  Uma abordagem possível é delimitar as palavras através de um carácter não alfanumérico. Os dois caracteres mais utilizados nesta técnica são o hífen “-“ e o sublinhado “_”. Por exemplo, o identificador “duas palavras” seria representado como "duas-palavras" ou "duas_palavras". O hífen é usado por quase todos os programadores de Cobol, Forth e Lisp e também é comum como seletor em Cascading Style Sheets. Na maioria das outras linguagens (p.ex., famílias C e Pascal) usa-se o hífen como operador de subtração, não estando, por isso, disponível para uso em identificadores, usando-se o sublinhado no seu lugar. Esta prática chama-se Snake Case.
• Palavras separadas por caixa de letras
  Outra abordagem é delimitar as palavras através do uso de letras maiúsculas. Neste caso o identificador “duas palavras” seria representado como "duasPalavras" ou "DuasPalavras". Esta técnica é chamada de Camel Case. Esta técnica tem duas variantes principais, uma que diz que a primeira palavra deve ter letra minúscula (“duasPalavras”) e outra que deve ter letra maiúscula (“DuasPalavras”). Existe alguma discussão sobre a correcta utilização destas variantes, mas hoje é mais comum aceitar-se que Camel Case designa a primeira variante (minúsculas) e que Pascal Case designa a segunda variante.

Metadados
Algumas convenções ultrapassam as meras regras de formato e grafia para a criação de nomes. Impõem também algumas regras para o seu significado. Alguma das técnicas usadas nessas convenções (especialmente nas mais antigas), são:

• Notação Húngara
  A Notação Húngara é talvez a mais conhecida destas convenções, que codifica o tipo de uma variável no seu nome, através de um prefixo. Por exemplo sNome indica que a variável é uma string ou nIdade, indica que a variável é um número inteiro.
• Notação posicional
  Uma técnica muito usada em notações curtas. P.ex. FTMARM01, onde FT é a aplicação – Facturação, M significa Menu, ARM é o módulo de Armazéns e 01 um número de sequência. Este tipo de convenção ainda é usada em mainframes dependentes de JCL e é vista também no formato MS-DOS 8.3 (máximo 8 caracteres, ponto separador e três caracteres para o tipo de ficheiro).
• Esquema de palavras compostas
  Um dos primeiros sistemas de convenções foi desenvolvido pela IBM e consiste no esquema de palavras PRIME-MODIFIER-CLASS. Um exemplo será IT_SEQ_NO, para significar “Item Sequence Number” ou “Número de Sequência do Item”. As palavras PRIME designavam as principais entidades do sistema, enquanto as palavras MODIFIER eram utilizadas como refinamento adicional, qualificação e legibilidade. Finalmente as palavras CLASSE deveriam ser apenas uma pequena lista de tipos de dados relevantes para uma determinada aplicação. As palavras CLASSE, colocadas como sufixo teve muitas vezes a mesma finalidade que os prefixos da Notação Húngara.

Namespces
O conceito de namespace (espaço de nomes) é bastante abrangente na ciência da computação. Genericamente, pode-se definir como um container que fornece um contexto para os elementos que armazena. P.ex., a nível do sistema operativo, um directório é um namespace. Muitas linguagens de programação disponibilizam namespaces como contextos para guardar identificadores. Algumas regras para estes espaços de nomes são as seguintes:

• Não podem existir dois identificadores iguais dentro do mesmo namespace;
• Podem existir namespaces dentro de outro namespace, formando uma árvore de espaços de nomes;
• Na mesma aplicação, podem existir classes ou funções com o mesmo nome, desde que estejam definidas em namespaces diferentes.

Os namespaces também necessitam de um identificador e, como tal, existem convenções de nomenclatura para a sua criação. Uma das convenções mais comuns, quer no Java, quer no .NET consiste em identificar os namespaces através de grupos de palavras em Camel Case ou Pascal Case, separadas por “.”. Cada um destes grupos tem um significado, conforme passamos a indicar:

• Nome da empresa ou organização
• Nome do produto ou tecnologia
• Nome do módulo
• Nome do sub-módulo e assim sucessivamente

Vejamos alguns exemplos:

Microsoft.Excel.Math.Random
java.util.stream
pt.governo.ministerio.financas

Convenções de Nomenclatura específicas

Java
Na linguagem Java, as convenções de nomenclatura para identificadores foram sugeridas e estabelecidas ao longo do tempo por várias comunidades, como a Sun Microsystems, ou a Netscape. Seguem-se alguns exemplos de convenções de nomenclatura da Sun:

• Classes
  Os nomes das classes devem ser substantivos, em Pascal Case. Devemos tentar manter os nomes das classes simples e descritivos. Usamos palavras inteiras, evitando siglas e abreviaturas, a não ser quando a sigla é muito mais usada do que a forma longa, como em URL ou HTML. Alguns exemplos:
  class ImageSprite
  class TextFileParser
• Métodos
  Os nomes de métodos devem ser verbos, em Camel Case. Alguns exemplos:
  run();
  runFast();
• Variáveis
  Os nomes das variáveis devem ser formatados em Pascal Case. Apesar de permitido em termos de sintaxe da linguagem, os nomes de variáveis não devem começar por “_” ou “$”. Os nomes das variáveis devem ser curtos, mas significativos. Não se devem usar nomes de apenas um carácter, excepto para variáveis ​​temporárias "descartáveis". Os nomes comuns para variáveis ​​temporárias são i, j, k, m, e n para inteiros; c, d, e e para caracteres ou strings. Alguns exemplos:
  int    i;
  char   c;
  float  myWidth;
• Constantes
  Os nomes de variáveis declaradas como constantes, devem ter todas as palavras em maiúsculas, separadas pelo carácter “_”. Alguns exemplos:
  static final int MIN_WIDTH = 4;
  static final int MAX_WIDTH = 999;

Microsoft .NET
As convenções de nomenclatura da Framework Microsoft .NET são muito semelhantes às da linguagem Java, em que a diferença mais evidente é a utilização do Pascal Case para o nome de métodos, em vez de Camel Case. Também existem pequenas diferenças entre as várias linguagens .NET, mas não muito significativas.

Recomendações

Finalizo com algumas recomendações baseadas na minha experiência pessoal:

• A primeira recomendação é que usem convenções de nomenclatura. Para além das convenções das linguagens e das que são usadas nos locais onde trabalham, criem as vossas próprias convenções e tenham a disciplina de as usar sempre que possível;
• Reforço a recomendação anterior para todos aqueles que estejam a liderar uma equipa de desenvolvimento, um projecto ou mesmo um departamento;
• Criem convenções para os componentes de framework, serviços, componentes de front-end, áreas de negócio, etc. Não são só os nomes das variáveis que são importantes;
• Utilizem a convenção dos namespaces (organização.aplicação.módulo) para evitar ambiguidades e colisões de nomes.