Sobre Python e Django
10/10/2009
No último post falamos sobre módulos reusáveis em Django, porém não falamos anteriormente o que é o Django. Para corrigir essa pequena falha, este post tratará sobre isso.
O Django é um framework para desenvolvimento web. A linguagem de programação usada com esse framework é o Python.
O Python é uma linguagem de programação de alto nível, interpretada, imperativa, orientada a objetos, de tipagem dinâmica e forte. Foi lançada por Guido van Rossum em 1991. Atualmente possui um modelo de desenvolvimento comunitário, aberto e gerenciado pela organização sem fins lucrativos Python Software Foundation.
Uma das principais características do Python é ser uma linguagem de fácil leitura e entendimento. Para a separação de blocos de código, a linguagem usa espaços em branco e indentação ao invés de delimitadores visuais como chaves (C, Java) ou palavras (BASIC, Fortran, Pascal). Diferente de linguagens com delimitadores visuais de blocos, em Python a indentação é obrigatória e não só uma boa prática de programação.
O Django usa uma arquitetura conhecida como MTV, Model-Template-View, que nada mais é que uma variação do modelo MVC (Model, View, Controller), arquitetura na qual separam-se as regras de negócios (Controller), os dados e métodos de acessos aos mesmos (Model) e as regras de apresentação (View). Essa separação tem por objetivo o desacoplamento da lógica entre essas camadas, de maneira que cada uma delas pode ser modificada sem alterar o funcionamento das outras. Essa arquitetura também facilita a modularidade do sistema.
No caso da arquitetura MTV, o framework Django é o que faz as vezes de controlador da arquitetura MVC. Sendo assim, na arquitetura MTV, o Controller não é responsável pela lógica do negócio e sim pelo funcionamento do sistema. Além de models, views e templates, no Django há também o URL dispatcher, middlewares e handlers e são estes que são encarados como Controller.
O URL dispatcher é o componente responsável em analisar os endereços requisitados pelo cliente e redirecionar essa requisição para a aplicação correta. Já o middleware é um conjunto de componentes que realizam pré e pós filtragens nas requisições, o que possibilita funcionalidade como internacionalização de uma aplicação e gerenciamento de sessões autenticadas.
No Model, são escritas as classes que designarão as tabelas no banco de dados. A manipulação dessas tabelas ocorre através do ORM (mapeamento objeto relacional) e, por isso, não é necessária a escrita de querys em SQL para a persistência dos dados. Uma outra vantagem é baixa preocupação com qual sistema gerenciador de banco de dados será usado, uma vez que o ORM suporta vários sistemas. Há suporte atualmente para MySQL, PostgreSQL e SQLite.
Nessa camada também devem ser escritas as regras de acesso às informações, regras para os eventos de cada modelo (métodos save, delete, etc.), e também regras genéricas para eventos que podem ser usados em mais de um modelo (sinais). Toda a lógica de manipulação da informação de uma aplicação estará em seu modelo.
Na camada View, são escritas as regras de negócio e as regras de apresentação do sistema.
Na camada Template é definida a forma de apresentação dos dados que a View envia. Com o sistema de templates do Django é possível criar heranças, ou seja, um template base contendo a estrutura básica do sistema e templates específicos que herdam as características deste template base e atribuem/criam suas próprias características.
Com o uso do framework Django, um projeto é um conjunto de aplicações. Uma aplicação é uma determinada funcionalidade que compõe um projeto. Por causa disso, há a idéia de aplicações plugáveis no Django que é uma aplicação que pode ser usada em mais de um projeto com nenhuma ou quase nenhuma alteração de código. Isso quer dizer que a aplicação deve ter seus próprios modelos, suas próprias views, seus próprios templates e encapsular o máximo possível de código que não se enquadre em um desses elementos.
Para quem deseja aprender Django uma boa referência é o Django Book, que é um livro disponível na web, escrito pelo Bennet, que é um desenvolvedor bastante conceituado em Django.
Outra referência bastante completa é a própria documentação disponível no site do django (http://docs.djangoproject.com/en/dev/).
Até mais!
Entry Filed under: Uncategorized. Tags: django, python.
2 Comments Add your own
Leave a Comment
Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <pre> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
Trackback this post | Subscribe to the comments via RSS Feed

1. Nathalia Sautchuk Patrício (nathysautchuk) 's status on Saturday, 10-Oct-09 17:19:38 UTC - Identi.ca | 10/10/2009 at 5:19 pm
[...] Post "Sobre Python e Django": http://febracev.wordpress.com/2009/10/10/pyhton-e-django/ [...]
2.
Wagner Mezaroba | 09/11/2009 at 8:38 pm
Discordo da tua definição de MVC. Controller não tem nada a ver com lógica de negócio. MVC é um padrão que tem por objetivo separar o domínio (os dados) de uma aplicação de sua visualização. Não é a respeito de camadas, é apenas interação entre objetos. Normalmente, o Model compreende a camada de domínio (mas não necessariamente é assim), o acesso a base e etc. Ou seja, a lógica de negócio não deve estar no controller! Quem vai representar o Model? A View, que usa o Controller como intermediário nessa comunicação.
A lógica de negócio devia estar em sua camada própria (repare que aqui estou falando em camadas, não em MVC). A lógica que pertence a uma entidade deve ficar nela, se você simplesmente fizer objetos que são um saco de atributos e remover a lógica que deveria ficar nele, vai quebrar um princípio básico da orientação a objetos: objetos são compostos por estado + comportamento. Nesse caso teus objetos só terão estado. Se essa é a função dele, tudo bem. Mas não coloque regras de negócio em controllers quando elas não deveriam estar lá (elas nunca deveriam). Mesmo quando uma lógica não é de responsabilidade de uma entidade, você pode ter outros objetos numa camada de domínio que os representem!
Analisando muitos frameworks web (não ficando contido apenas no mundo python) é fácil enxergar um padrão. Você faz requisições nos controllers (direta ou indiretamente), os quais acessam o model e despacham uma view, a qual representa o modelo. No Django essa view não é como os dados são representados, e sim quais são dados (como está exposta na FAQ), daí a nova nomenclatura.
Enfim, uma opinião contrária! (:
Falou.