[pyar] [Discusión] Django y Single Responsability Pattern

[Jose Selesan]

Hola Maxi. Lo de MVT en django y que la vista en realidad es un controlador
de MVC ya me parecía.

Está claro que la arquitectura cada uno la puede armar a gusto, a lo que
apuntaba justamente es a si hay una lista de "buenas prácticas". A mi me
gusta separar la persistencia de la lógica de negocios, pero a su vez me
gusta que cierta lógica de negocios esté en las clases (por ejemplo, si
tengo una clase cuenta corriente, yo lo que hago es tener la lista de
movimientos, el método para calcular el saldo y para hacer un depósito o
extracción en la misma clase, pero no es la clase la que sabe como
persistirse (el ORM es el encargado, las clases son agnósticas de la
persistencia), y para hacerlo así, el modelo ofrecido por django no sirve.

José


2014-07-28 17:18 GMT-03:00 Maxi <maxirobaina en gmail.com>:

> El día 28 de julio de 2014, 16:52, Jose Selesan <jselesan en gmail.com>
> escribió:
> > Buenas gente!. Estoy leyendo sobre Django (empecé por Django, si no me
> gusta
> > veré Flask o algún otro web framework) y una de las primeras cosas que me
> > llamó la atención es que los modelos son más bien modelos de datos, ya
> que
> > especifican los campos y heredan el comportamiento para almacenar en la
> base
> > de datos.
> >
> > Ahora bien, en los ejemplos que vi, desde la vista misma (ya sea una
> Class
> > View o una función) se persisten las entidades. Esto está bien en
> ejemplos
> > sencillos, pero en casos más complejos, ¿no viola el principio de
> > responsabilidad única? Por ejemplo cuando creo una factura, debo hacer
> las
> > validaciones de negocios (que el cliente tenga saldo, que haya stock
> > suficiente, etc), actualizar el stock de los productos, actualizar el
> saldo
> > del cliente y persistir la factura con sus items. ¿Donde ponen ese
> código?
> > ¿En la vista? ¿O se crea una clase de de servicio como suele usarse en
> Java
> > o .Net?
>
>
> Hola José,
>
> Lo que generalmente confunde en django es que al patrón MVC, django lo
> llama MVT (Model, View, Template), en donde la vista (view) es en
> realidad el controlador, y el template la vista.
> Independientemente de esto, la forma en que vos diseñes la
> arquitectura de tu aplicación corre un poco por tu cuenta, no siempre
> tenés que atarte a este modelo. Para mi la capa de persistencia
> debería estar siempre separada de la lógica del modelo de negocios,
> por lo tanto me resulta incomodo tener por ejemplo una clase Cliente
> con un método "facturate" y que ese método resuelva la lógica de la
> facturación. En todo caso tendría una clase Facturador la cual
> recibiría el cliente (o lista de clientes) a facturar. Pero ya te digo
> va en en la estructura que cada uno quiera imponer no necesariamente
> tiene que ser así. Si vos querés poner esa lógica en los módelos
> tampoco estaría mal. No se como será en java o .net
>
> Saludos.
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20140728/0a72d0c3/attachment-0001.html>