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

[Luis Masuelli]

En JAVA o .net es lo mismo. Los principios son mas o menos iguales para todos. Vi aplicaciones en Struts que tenian capa de servicios (logica comun a varios controladores, separada de los actions que hacen uso de ellas), y aplicaciones en las que los controladores acceden directamente a los objetos de hibernate (en algunos casos mas horribles, los controladores no tenian ni siquiera tenian un filtro/interceptor que haga el OpenSessionInView - aunque igual eso era en apps mas chiquitas) y los respectivos modelos.

> From: maxirobaina en gmail.com
> Date: Mon, 28 Jul 2014 17:18:01 -0300
> To: pyar en python.org.ar
> Subject: Re: [pyar]	[Discusión] Django y Single Responsability Pattern
> 
> 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/fadce817/attachment.html>