Hola, Hugo.

Me alegro que el artículo te haya gustado, y también que seas el primero -espero que no el último- en comentarlo.

>Mi primera pregunta es respecto a la cohesion (bah! me parece que no es esa la palabra que busco, no se ni para que trato de usar palabras técnicas si no las conozco!)... a ver si me explico, en tu ejemplo el controller tiene conocimiento íntimo (a ver si con esto traemos mas audiencia <g>) del View, como se ve en el método SetEventHandlers, y yo habia entendido (solo leí, aparte de tu artículo, "la biblia" y no se me hizo para nada fácil, así que mucho no entendí <g>) es que lo que MVC trata de lograr es desacoplar los tres (Aunque entiendo lo que dices de que en Foxpro controller y view tienden a estar acoplados). Entonces la pregunta sería (ja! pensaban que me había olvidado), es aquí donde entraría el Observer pattern? De esta manera se podría usar el controller para diferentes view, es esto así o estoy "meando fuera del tarro"?

Pues bien, la verdad es que no hay manera absoluta de desacoplar todo, porque en tal caso sería muy dificl que las componentes coincidan y puedan trabajar juntas. En este caso, el Controller minimiza el acople entre entre Model y View, y eleva la cohesión de estos últimos, ya que hace que no deban preocuparse por muchos fenómenos externos, sobre todo en el caso del Model.

Ahora bien, y esto es lo que todavía no hemos visto (recuerden que es el primer artículo y aun no mencioné ningún otro patrón), en realidad,el Cotroller no se acopla a una View en particular, sino a un interfaz que nuestra View debería implementar. Esto no esa algo muy directo en VFP, pero podemos hacerlo utilizando clases abstractas. Cualquier View necesitaría solamente tener cierto métodos para poder ser utilizada por el Controller. El resto podría ser variable.

Sin adelantrme mucho, el Controller es más un Mediator que un Observer. La View podría ser un Observer activo o pasivo, según el caso, pero ya veremos eso en detalle en uno de los próximos artículos.

Un abrazo,