... | ... | @@ -122,6 +122,40 @@ Apesar do Django ter uma clara influência do MVC eles realmente conseguiram faz |
|
|
| controller | view |
|
|
|
|
|
|
|
|
|
Uma questão que aparece a pessoas que começam a aprender pelo Django é: "Onde eu coloco esse código de lógica de negócio aqui?" resposta correta: na model. Isso não é obvio pra um iniciante pois na documentação do Django a model as vezes é tratada só como objetos que agrupam os dados que vão parar no banco de dados.
|
|
|
A resposta é na model pra tentar criar aquela camada de lógica de negócio que não é tão estimulada fora dos modelos de desenvolvimento do java. E isso é necessário pra evitar duplicação de código no controller e *encapsular* interações complexas entre os dados.
|
|
|
|
|
|
Como exemplo, o código usado depois que uma análise foi concluida:
|
|
|
|
|
|
```Python
|
|
|
# ...
|
|
|
|
|
|
class Submission(models.Model):
|
|
|
# ...
|
|
|
def set_done(self, time):
|
|
|
self.processed = True # ja foi processado ou não
|
|
|
self.process_time = time # quanto tempo levou
|
|
|
self.done_in = timezone.now() # dia e hora que foi processado
|
|
|
|
|
|
self.save()
|
|
|
```
|
|
|
|
|
|
Marcar uma análise como feita ou não, envolve vários campos que devem ser mantidos com coerência. E isso ainda é pouco, ainda falta:
|
|
|
|
|
|
1. marcar essa análise como a análise atual do curso
|
|
|
2. descobrir qual era e desmarcar a anterior
|
|
|
3. anunciar ao objeto curso, que a análise atual mudou
|
|
|
3. possivelmente mandar emails
|
|
|
|
|
|
E esse código seria chamado de vários locais diferentes:
|
|
|
- da fila de análises (ainda por fazer)
|
|
|
- da interface de administração
|
|
|
- da linha de comando (`python manage.py analyze 42`)
|
|
|
|
|
|
Se fosse código jogado no controller isso com certeza daria problema em algum momento, porque teriamos que manter todos os controllers fazendo o mesmo. Também facilita a organização porque já está dentro do próprio objeto.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Use template tags
|
|
|
|
... | ... | |