Se solicita el manejo / acceder a la base de datos en las vistas de una buena práctica?

Question

Tengo un problema con el MVC de Django. Yo entiendo que este no es el tradicional MVC, pero hace hincapié en la documentación que a lo largo de hecho separa presentación de la lógica de negocio. Sin embargo, el tutorial trata de una pieza de código como el siguiente:

def vote(request, poll_id):
    p = get_object_or_404(Poll, id=poll_id)    

    try:
        selected_choice = p.choice_set.get(id=request.POST['choice'])
    except (KeyError, Choice.DoesNotExist):   
        return render_to_response('polls/detail.html', 
                                  { 'poll': p, 'error_message': 'You didn''t select a choice.' } )
    else:
        selected_choice.votes += 1
        selected_choice.save()
        return HttpResponseRedirect(reverse('mysite.polls.views.results', args=(p.id,)))     

    return render_to_response('polls/vote.html', {'poll': p})

(esto es tal vez no es exactamente el mismo que en el tutorial, ya que es mi aplicación, pero el concepto es el mismo)

En esta parte, se encarga de la solicitud, y (posiblemente) inserta un registro en la base de datos.

No es esto malo? ¿No debería estar en algún lugar en el modelo? ¿Qué ocurre en los escenarios más complejos? no se consiguen los puntos de vista atiborrada de montones de código db-intensiva, y la presentación mínima? Hacer aplicaciones más grandes tienen mucho más tiempo (como en LOC) puntos de vista?

Edit: Preguntas Esta entrada no responde a mi pregunta

Answer 1

Nada está escrito en piedra. En mi mente:

• Vistas describen lo que los datos van a ser presentados (esto es específico de negocio, por lo que se considera como la lógica de negocio, pero no reglas de negocio)
• modelos describen el acceso a datos y reglas de negocio (aquí es donde me concentro la mayor parte de las normas específicas de dominio sobre mis datos)
• Las plantillas son la capa de visualización, donde se formatea los datos seleccionados en las vistas.

Una vez dicho esto, porque me gusta más la filosofía de plantillas magras, simples; A veces tengo vistas haciendo un montón de masticación de los datos para hacer el trabajo de las plantillas más simple. No pensar en que, como código de visualización, pero he tenido algunas personas me dicen que es.

Acerca de su ejemplo, se dice:

  

En esta parte, se encarga de la solicitud, y (posiblemente) inserta un registro en la base de datos.

No entiendo lo que quieres decir ...

Este punto de vista está utilizando el modelo para crear un nuevo registro. Primero solicita el modelo de actualización:

selected_choice = p.choice_set.get(id=request.POST['choice'])

A continuación, se modifica el modelo y ahorra:

selected_choice.votes += 1
selected_choice.save()

Toda la lógica de salvar (incluyendo cualquier overriden Guardar método ()) está en el modelo.

Hay que tener código para manejar las acciones sobre los modelos en alguna parte. Esos son los puntos de vista. Ellos se encargan de la búsqueda de datos para la visualización y manejar el procesamiento de solicitudes de modificaciones.

Answer 2

Usted está entendiendo mal lo que cada uno de los componentes son para. En Django, la vista es para la lógica negocio , que es exactamente lo demuestra el ejemplo. lógica de visualización pertenece en la plantilla.

Dicho esto, si usted tiene lógica del modelo específico muy complejo, que sin duda puede escribir un método en el modelo -. Pero todavía tendrá que llamarlo desde el punto de vista, por supuesto

En cualquier caso, al igual que todos los patrones de diseño, MVC no es más que una guía de cómo la estructura de su aplicación, no es una regla dura y rápida.