Alguns veêm as coisas como são…

Neste segundo artigo eu pretendo expor, através da interpretação da documentação, algumas idéias que os desenvolvedores do Django colocam em prática.

Geral

Baixo acoplamento e alta coesão

Estas são as qualidade que separam o bom software do ruim. Estes termos foram
formalizados durante a invenção da
Programação Estruturada e se aplicam muito bem ao desenvolvimento
Orientado a Objetos.

O Django reforça estas premissas.

As várias camadas que compõe o Django funcionam independentemente umas das
outras. Por exemplo, a camada de acesso a dados não sabe nada sobre como mostrar
dados em uma página e por sua vez a camada de templates não sabe o que são
requisições WEB.

Menos código

Opa!! Isso é Python.

Desenvolvimento Rápido

Com Django o desenvolvimento WEB é muito rápido. Parece Lego!

Don’t Repeat Yourself (DRY)

Não Repita. Redundância é ruim. Por isso, cada pedaço de código ou dado deve
residir em um único local.

Explicito é melhor do que implícito

Esta é uma das características que mais gosto no Django. Na realidade este é um
dos princípios do Python, e significa que o Django não deve fazer “Magia”. Isto
fica claro quando você olha para o código do Django, chega a ser ridículo de tão
óbvio.

Consistência

A consistência do código deve ser percebida tanto em baixo-nível(escrita do
framework) quanto em alto-nível(código que você usará).

Models

Explicito é melhor do que implícito

Campos não devem assumir comportamentos baseados em seu nome. Comportamentos
devem basear-se em palavras chave e em alguns casos no tipo do campo.

Database API

Deve escrever código SQL eficiente, possuir sintaxe clara e poderosa e permitir
a escrita manual de código SQL quando necessário.

URLs

Devem ser flexíveis, encorajar as melhores práticas(esqueça: “index.asp”) e
devem facilitar a leitura através dos robôs(search-engine).

Baixo acoplamento

URLs não devem estar acopladas a funções em Python.

Sistema de Templates

Característica:

Separar a lógica da apresentação;

Evitar redundância;

Não acoplamento ao HTML;

Assumem a competência do Designer- esqueça editores WYSIWYG;

Tratar espaços em branco – eles estão lá, então devem aparecer na página;

Não invente uma nova linguagem – templates são para designers e não para
programadores;

Devem ser seguros;

Extensiveis – esta é a filosofia por de trás de “templateTags” e “filters”;

VEWS

As views devem ter acesso direto ao “request object”.

Não devem estar acopladas a nenhum sistema de templates.

Devem diferenciar POST de GET.

Simplicidade

Escrever uma view deve ser simples como escrever uma funcão em Python.