EN QUE CAPA REALIZAR LAS REGLAS DE NEGOCIOS

[Roberto Esteban...]

Estimados

Les comento que me encuentro en una etapa de trabajar mucho con el ADMIN de DJango y me nacio la duda donde es la implememtacion correcta de las reglas de negocio que voy generando

Por ejemplo 

Cuando creo un usuario, lo agrego como usuario de Django y eso lo hago y eso lo realizo en el models de mi app

En otra app proceso algunos datos del modelo y los guardo en el admin de la app

Mi duda es donde realmente deberia realizar mis reglas de negocio dentro de cada app

Eso

Saludos

R.

[Daniel Chimeno]

Hola,

En este enlace (anticuado pero válido) http://librosweb.es/libro/django_1_0/capitulo_5/el_patron_de_diseno_mtv.html

puedes ver:

M significa "Model" (Modelo), la capa de acceso a la base de datos. Esta capa contiene toda la información sobre los datos: cómo acceder a estos, cómo validarlos, cuál es el comportamiento que tiene, y las relaciones entre los datos.
T significa "Template" (Plantilla), la capa de presentación. Esta capa contiene las decisiones relacionadas a la presentación: como algunas cosas son mostradas sobre una página web o otro tipo de documento.
V significa "View" (Vista), la capa de la lógica de negocios. Esta capa contiene la lógica que accede al modelo y la delega a la plantilla apropiada: puedes pensar en esto como un puente entre el modelos y las plantillas.

Espero te sirva.

Un saludo

[Roberth Solis Martínez]

Eso lo haces en el views.py de cada aplicación

[Diego Ponce de León]

Es curioso que se recomiende poner la capa de negocio en una vista. En cualquier otra tecnología esto es un anti-pattern, aunque parece que en Django es algo habitual.

Yo personalmente dejo las vistas lo más sencillas posibles, y coloco la capa de negocio en una clase a parte que instancio en la vista.

De esa manera tus vistas se pueden testear más fácilmente con mocks y la capa de negocio se puede testear por separado de la vista.

Saludos

--
--
Ha recibido este mensaje porque está suscrito a Grupo "Grupo de Usuarios del Framework Django de habla hispana" de Grupos de Google.
Si quieres publicar en este grupo, envía un mensaje de correo
electrónico a djan...@googlegroups.com
Para anular la suscripción a este grupo, envíe un mensaje a django-es-...@googlegroups.com
Para obtener más opciones, visita este grupo en http://groups.google.com.bo/group/django-es.
---
Has recibido este mensaje porque estás suscrito al grupo "Django-es" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a django-es+...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Roberto Sánchez Almonacid]

1.- Primeramente gracias por su apoyo a todos

2.-Diego como haces eso de instancias tus reglas de negocios en la vista

3.- En el caso de admin el archivo admin.py pasaria como la view?

--

Atte.

Roberto Sanchez A.

@robertoesteban
+56 9 93691076

[Roberth Solis Martínez]

Estoy de acuerdo Diego, pero al amigo no le vas a decir que haga un Singlenton o un patrón Template en Python, POJO u terminos un poco complejos, que primero vea como ponerlos y luego avance, me parce que está en la introducción a Django

[Diego Ponce de León]

Si claro, si está empezando, mejor no complicarse.

Pero lo de instanciar es como cualquier clase/objeto. Nada especial:

class SuperBusinessLogicManager:

    def Something(self):
       return 'este método hace maravillas'

En tu vista o donde quieras:

manager = SuperBusinessLogicManager()

fact = manager.Something()

print(fact)

El mié., 10 feb. 2016 a las 23:21, Roberth Solis Martínez (<robert...@gmail.com>) escribió:

Estoy de acuerdo Diego, pero al amigo no le vas a decir que haga un Singlenton o un patrón Template en Python, POJO u terminos un poco complejos, que primero vea como ponerlos y luego avance, me parce que está en la introducción a Django

--

[monoBOT]

Yo meto casi toda la lógica en los modelos ... todos los métodos necesarios y desde las vistas como mucho llamo a éstos métodos.

El primer proyecto tenía la lógica en las vistas y no puedes creer todo lo que te repites por culpa de eso ... Recuerda dont repeat yourself

El 10 de febrero de 2016, 20:21, Roberth Solis Martínez <robert...@gmail.com> escribió:

Estoy de acuerdo Diego, pero al amigo no le vas a decir que haga un Singlenton o un patrón Template en Python, POJO u terminos un poco complejos, que primero vea como ponerlos y luego avance, me parce que está en la introducción a Django

--

--
Ha recibido este mensaje porque está suscrito a Grupo "Grupo de Usuarios del Framework Django de habla hispana" de Grupos de Google.
Si quieres publicar en este grupo, envía un mensaje de correo
electrónico a djan...@googlegroups.com
Para anular la suscripción a este grupo, envíe un mensaje a django-es-...@googlegroups.com
Para obtener más opciones, visita este grupo en http://groups.google.com.bo/group/django-es.
---
Has recibido este mensaje porque estás suscrito al grupo "Django-es" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a django-es+...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

monoBOT

Visite mi sitio(Visit my site): monobotsoft.es/blog/

[Charly Román]

Por ahí había una estrategia que se llama "fat models skinny views": http://redbeacon.github.io/2014/01/28/Fat-Models-a-Django-Code-Organization-Strategy/

Saludos!

Charly Román
Software Developer
http://croman.mx

[Roberto Sánchez Almonacid]

Que mas decir muchisimas gracias

[Phoenix]

La "logica de negocio" bien entendida va en las vistas, lo que no quiere decir que uno confunda comportamiento del objeto con lógica de negocio.

En las vistas servite de todos los métodos que necesites implementar en el objeto, de esa manera no vas a repetir código, muchas veces uno pone en las vistas cosas que debería estar en el  modelo. 

[Franklin Sarmiento]

De acuerdo con Phoenix, uno debe saber y entender y diferenciar el comportamiento de los objetos y el comportamiento de las vistas, en un MVC sencillo serían los controllers, y la logica de Usuarios > Peticiones > Data se aplica en los controladores pero que y como debe actuar la información que se esta solicitando se hace siempre del lado de los modelos.

--

--
Ha recibido este mensaje porque está suscrito a Grupo "Grupo de Usuarios del Framework Django de habla hispana" de Grupos de Google.
Si quieres publicar en este grupo, envía un mensaje de correo
electrónico a djan...@googlegroups.com
Para anular la suscripción a este grupo, envíe un mensaje a django-es-...@googlegroups.com
Para obtener más opciones, visita este grupo en http://groups.google.com.bo/group/django-es.
---
Has recibido este mensaje porque estás suscrito al grupo "Django-es" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a django-es+...@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

FGSC

[Diego Ponce de León]

Poner lógica en las vistas en un anti patron. Por mucho que insistáis .

¿Habéis oído hablar del desacoplamiento ?
Cada parte lógica debería ser independiente del resto, cumpliendo una sola función, cuanto más pequeña mejor.

Poniendo lógica en una vista estarás obligado a instanciar la vista para usar dicha lógica, y sólo desde ahí. ¿Que pasa si quieres usar la misma lógica desde otra parte de la aplicacion? Por ejemplo unit test, un signal de django, un cronjob, etc.

Tu lógica queda "acoplada" a la vista.
Podéis encontrar toneladas de información en google sobre esto