Hola, Ricardo.

>Martín, siguiendo con el tema ahora en el foro en español.
>Preguntaba como implementar correctamente el MVC usando VFP. El problema que me enfrenté, es pasando algo de código entre JAVA y VFP y tratando de ser lo más purista posible en el uso de patrones de diseño.
>
>Te planteo un ejemplo extremadamente básico y te pido tu opinión al respecto.
>Un formulario con un solo botón que imprime un mensaje.
>
>1) Capa VIEW del pattern en VFP
>directamente creo un form
>

>CREATE FORM mvcTest
>

>Y le agrego un command button llamado cmdSaludo
>y una propiedad llamada oCtrl que instancia la clase controller

Primer consejo (no pedido [jeje]): que la propiedad se llame oController en lugar de oCtrl. Los nombres descriptivos son tan importantes como la arquitectura, para mi.

>2) Capa Controller del pattern
>creo un PRG para definir una clase llamado ctrlTest.prg
>con el siguiente código:
>

>DEFINE CLASS ctrlTest as Custom
>	PROTECTED cSaludo as String
>		
>	PROCEDURE Init(cStr as String)
>		this.cSaludo = cStr
>	ENDPROC
>		
>	PROCEDURE Saludar
>		MESSAGEBOX(this.cSaludo)
>	ENDPROC
>ENDDEFINE
>

>En el método Load del formulario agrego el siguiente código:
>

>SET PROCEDURE TO ctrlTest.prg additive
>This.oCtrl = CREATEOBJECT("ctrlTest")
>

No entiendo porque seteas el contenido de la propiedad en el constructor si no vas a pasarlo al instanciar el Controller. De hecho, llamar al constructor es algo que jamás deberías hacer en mi opinión. En todo caso, deberías poner un método DefinirSaludo( cMensaje as String ), pero en principio si haces esto desde la View no estás ganando nada. El objetivo el Controller es hacer de intermediario con el Model, no hacer un eco de lógica que tengas en la View.

>El evento click del botón el siguiente código:
>

>Thisform.oCtrl.Init("Hola UT!")
>Thisform.oCtrl.Saludar()
>

>Y por último en el evento Unload del form:
>

>RELEASE PROCEDURE ctrlTest
>This.oCtrl = null
>

>3) Capa Model del pattern
>es aplicable ?

Por supuesto que es aplicable. Si no hay Model, no hay MVC. Lo que pasa es que en tu ejemplo estás sobresimplificando las cosas. Te hago una variante más abajo.

>Funcionar, funciona, pero mi duda es esi correctamente aplicable. Por lo pronto me surgen cuatro preguntas:
>1) La capa Model es aplicable ?
Definitivamente si.

>2) La definición de la clase es de tipo Custom . Es correcto ?
>3) Cuando aplicar en la definición de clase tipo Session ?
Utilizaría Session preferentemente, con una sesión de datos privada. Si por sencillez de uso o por una decisión conciente quieres que el Controller instancie cursores que la View pueda ver (por ejemplo para vincularlos con grillas) entonces tu Controller puede basarse en Session pero tener DataSession = Default (no recuerdo el valor). De esta forma básicamente te reservas la posibilidad de cambiar esto a futuro. En realidad deberías basarlo en ControllerSession que sería una subclase de Session con datasession default.

>4) la instanciación de la clase dentro del form no me parece muy elegante, pero quiería evitar tener un main (o un programa lanzador) con muchas definiciones y objetos instanciados sin ser usados.

La instanciación del Controller usualmente se hace desde la View, ya que esta tiene una dependencia con éste. Lo importante es que puedes tener varias Views que utilicen el mismo Controller. Puedes utilizar Dependency Injection para desacoplarlo más, pero esto lo dejamos para otra vez.

Veamos ahora un ejemplo más consistente (sin código porque es tarde; si lo necesitas mañana lo escribo):

Tu View puede ser un formulario, como antes, y en el constructor creas la referencia (puede ser en el Load en VFP).

El Controller instancia a su vez uno o varios Model (objetos de negocios del estilo Cliente, Factura, Producto, etc). Estos son entidades puras que no saben nada de Controllers ni Views, pero el Controller sabe como manipularlos y trabajar con ellos, y actúa como Mediator entre ellos y el formulario. Uno de los mecanismos más desacoplados es que el Controller se suscriba a eventos de los Models (puedes usar BindEvent para ello), y los levante a su vez (tal vez transformados) para que la View se suscriba a los del Controller, de manera que al cambiar algo en un Model, la View reciba esos cambios.

Puntos importantes: el Controller no debe tener JAMAS referencias a la View, ni los Model al Contoller. La dependencia es hacia abajo en MVC. Hay maneras de evitar estas dependencis también, que prefiero en lo posible, pero MVC funciona así y es un compromiso bastante "barato" si mantienes las reglas de juego.

Bueno, espero no haberte aburrido. Mañana me cuentas si te hace falta un ejemplo de código y lo escribo en VFP para enviarlo y que lo discutamos en el foro.

Un abrazo,