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: , .

2 Comments Add your own

  • 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.

    Responder

Leave a Comment

Required

Required, hidden

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


Blogroll

Tópicos recentes

Licença

Creative Commons License
Este blog está licenciado sob uma Licença Creative Commons.

Mais…