hola a todos.

estoy dudando cuales serian las limitaciones de esos dos patrones para el caso web.

para el caso desktop (tomado como una aplicacion no distribuida), en mvc tenemos que el controller actualiza el modelo, la vista conoce e interactua con el controller, y la vista a su vez es un observer del modelo ( el modelo notifica a la vista de cualquier cambio que recibe a traves de bindings por lo general )

en mvvm para el caso desktop es practicamente lo mismo, pero el binding es entre la vista y el "viewModel", la vista no sabe nada del modelo del dominio.

pero como se interpreta mvc para el caso web (o sea html sobre http) ?
es imposible que sea mvc "puro" justamente porque la vista no puede ser un observer del modelo por el funcionamiento de http.
dicho de otra forma, como se interpreta mvc para el caso web ? quienes serian los controllers por ejemplo ?

en el caso de mvvm para web es lo mismo: no puede haber binding entre "ModelView" y "View" por lo que decia de http.
entonces ?

cualquier sugerencia/aporte me sirve

saludos!

pd: aclaro que no cursé con dodino, por eso pregunto.

segun como yo lo entiendo, la definicion purista de mvc no cabe realmente en la web, como vos decis


sin embargo, la vida (?) hizo que todos esos terminos se aplicaran en productos como asp.net mvc y otros largos etc

o esa fue la idea que me dejaron los muchachos de arquitectura de proyectos it

en todo caso si podes tener mvc/mvvm todo del lado del browser, si tenes algun framework tipo angular o de ese estilo: vos cambias el modelo en algun contexto y se te actualizan las vistas y viceversa

Sobre MVVM como decís interactua con tu ViewModel, pero calculo que tu ViewModel puede ser un objeto nuevo para comunicar a la vista con el Modelo, o también podría ser el mismo modelo, depende si te alcanza o no el Model para ser utilizado por la vista (cuando no te da la nafta con un Model usaría un objeto nuevo para agregar lo que falta de comportamiento y usaría ese como ViewModel).

Como dice Gonza, a menos que utilices los patrones esos del lado del cliente, con Frameworks como Angular. Y que no utilices otras tecnologías como websockets, de cajón no se puede implementar el MVC clásico. En la visión tradicional de MVC web, tu vista llamaría al servidor por medio de HTTP pasandole la información relevante, para que actualice su modelo y como respuesta obtendría una nueva Vista. El controller seguiria interactuando con las vistas y modelos, pero el estimulo en este caso siempre lo iniciaria la vista.. Es en principio lo que se me ocurre.

Igual, como aclaras que no cursaste con Dodino, hay que ver que espera tu docente como respuesta.

leiste la biblio? o no esta muy explicado ahi?

CarooLina a ese nivel de explicacion, es decir, de detallar en donde está cada componente y que responsabilidad tiene cuando es web, te digo la verdad, no lo encontré. puedo haber leído mal pero no lo encontré.
como tampoco puedo encontrar la parte donde se explica con que criterio elegir entre strategy y decorator (por dar un ejemplo) cuando hay que tener en cuenta la UI. o sea, vi que en un final preguntaban en que afecta la ui, o que es mejor desde el punto de vista de la ui, teniendo en cuenta identidad, delegacion y demas.
tampoco pude encontrar lo que dijo dezine18 en el otro tema (el del final del 14/2/15) en referencia a que depende de si la app es desktop o web. se que si no es desktop, va a tener las limitaciones por las que abrí este tema. pero más que eso no se me ocurre. además en web tenés las variaciones REST y component(wicket), por decir algunas, y creo que también eso influría un poco.

edit:

otra cosa que no pude encontrar es: como hacer un modelo 100% independiente de la ui.
si usas mvc puro, tenes que hacer el modelo observable (sea declarativamente o con codigo a mano).
pero si usas REST por ejemplo, no lo necesitas.

okey! gracias. Mañana lo voy a releer

Ejemplo super simplificado de como se maneja en PHP. MVC web cliente-servidor, framework Laravel. En este caso sin usar ajax ni nada que refresque la vista de manera asincrónica. Para refrescar hay que hacer una nueva petición. Supongamos que querés ver la ficha de un cliente:

url: [GET]clientes/{id_cliente} ej: tusitio.com/clientes/4

 //La clase que representa a la entidad cliente en tu modelo y te permite su acceso y persistencia y contiene parte de la lógica de //negocio

class Cliente

{

 //Cosas varias que querés poder hacer con tu tabla de clientes

}



//El controller abaraja la petición (un archivo de rutas determina que método de que controller se encarga)

class ControladorClientes {



 //Método que se encarga de la petición

 public function verCliente($idCliente)

 {

  //Obtengo el cliente

  $unCliente = Cliente::find($idCliente);



  //Valido que exista como para hacer algo

  if(is_null($unCliente))

   return View::make('pantala_error')->with('mensaje', 'El cliente especificado no existe');



  //Datos que le voy a pasar a la vista, si no quiero pasarle directamente el objeto $unCliente

  $datosCliente = array('nombre' => $unCliente->nombre, 'apellido' -> $unCliente->apellido);



  //Si todo anduvo bien le mando a la vista que contiene el form, los datos que requiere

  return View::make('ficha_ciente')->with('cliente', $datosCliente);

 }



}





//La vista con el diseño (ficha_cliente.blade.php)

...

<h1>Datos del cliente {{$cliente['nombre']}} {{$cliente['apellido']}}</h1>

...

//Finalmente llega al browser
...
<h1>Datos del cliente Cosme Fulanito</h1>
...

Si somos "puristas" eso no es MVC ya que como comentaron mas arriba no existe MVC en tecnologias web del lado del servidor (de hecho creo que hoy en dia ningun framework PHP se vende a si mismo como "MVC", a diferencia de lo que sucedia hace unos años atras)

Ya que estamos con PHP un par de links copados sobre el tema

http://blog.ircmaxell.com/2014/11/a-begi...r-web.html
http://blog.ircmaxell.com/2014/11/altern...o-mvc.html

En esos mismos links que pasaste se habla de MVC como patron (que no estoy seguro de si no podría implementarse mediante web sockets) y como concepto. Laravel, Symphony, etc apunta mas a los segundo (cada uno como le pareció). En Java, Spark hace mas o menos lo mismo y así. El termino técnico es MVC a los martillazos

me referia a que el ejemplo es 100% PHP y ahi es donde MVC no existe ya con websockets, java, etc., estamos en otro tema

como el debate está, aprovecho para hacer una pregunta:

hay alguna forma de hacer el modelo 100% independiente de "todo lo demas" ? o sea, plantear el modelo y despues usarlo en arena, swing, jsp, rest sin ningun tipo de cambios.

si, por ejemplo, empezas programando un mvc con swing (o arena) tenes la clases del modelo usando @Observable ó, peor todavia, con el binding hecho a mano. Entonces si pasas a rest (por ejemplo), tenés que ir y sacar todas esas anotaciones y/o codigo en las clases del dominio que ya no te hacen falta.
entiendo que con anotaciones es una cuestion de "search & replace", pero me hace ruido que no se pueda tener un modelo 100% independiente.

espero que se entienda lo que estoy preguntando.