Articulos MVP Joanna Carter
#1
Escrito 10 febrero 2011 - 07:22
¿Alguno de ustedes ha leído estos artículos?
Me gustaría poder compartir ideas y conceptos sobre los mismos.
#2
Escrito 10 febrero 2011 - 08:13
Salud OS
#3
Escrito 10 febrero 2011 - 09:52
Acabo de bajar los artículos y el código fuente y esto ha quedado formando parte de mi biblioteca.
Luego le doy una mirada para determinar si lo imprimo.
Me estoy por envolver, justamente, en los principios del concepto MVC y MVP junto con las técnicas del parón Observer por lo que creo que esto me dará una mano.
Saludos,
#4
Escrito 10 febrero 2011 - 12:16
Y si además tengo presente que está en inglés, uff...
Al revisar el código fuente noté que el proyecto está pidiendo un form1 y no está entre los archivos, y además me da unos warnings.
Saludos,
#5
Escrito 10 febrero 2011 - 12:24
Eso de que falta el Form1, lo resolví poniendo el código fuente en la carpeta Source y el DPR fuera de la misma o como dicen al lado.
Se aplica bastante los patrones de diseño. Como estoy por escribir un par de plantillas para alivianar mi desarrollo, me estoy leyendo esta documentación y un par más por ahí.
Si que es un cambio radical de metodología y/o visión de programación, además de que los mismo piden prácticamente renunciar al DB-Aware y eso es algo que no haré; por lo tanto me limitare a estudiarlo y usar lo que me convenga.
#6
Escrito 10 febrero 2011 - 12:48
¿Dices que el código fuente lo copie a la carpeta MVPArticles\Source\ y al .dpr lo ponga en MVPArticles\?Saludos.
Eso de que falta el Form1, lo resolví poniendo el código fuente en la carpeta Source y el DPR fuera de la misma o como dicen al lado.
Así parece, de lo he ojeado a los documentos habla o toca patrones que incluso no he estudiado... como Command e Iterator. Se me hace que el artículo no es para simples inciados en los patrones; en especial si uno no estudió los patrones a que recurre.Se aplica bastante los patrones de diseño.
Me va a resultar mejor a mi ponerme a repasar bien los patrones en lo que estoy flojo y continuar con los que me faltan y recién probar suerte con estos artículos.
Pues yo no utilizo componentes DB-aware, como he dicho en otras ocasiones no me convencen del todo. Si bien es uno de los puentes fuertes de Delphi, desde que toqué el tema OO, el concepto de 3 capas: Interfaz, Lógica, Datos y le metí al tema de patrones como que anda medio descolgado de la teoría de la "independencia de capas" y no me decido totalmente hacia adonde apuntar... aunque mi cabeza tiende más hacia el lado más técnico y purista OO.Si que es un cambio radical de metodología y/o visión de programación, además de que los mismo piden prácticamente renunciar al DB-Aware y eso es algo que no haré; por lo tanto me limitare a estudiarlo y usar lo que me convenga.
Para quien ha utilizado los componentes DB-Ware y no ha implementado clases de negocio, y otras capas intermedias realmente le supondrá un cambio bastante radical.
Saludos,
#7
Escrito 10 febrero 2011 - 01:05
Sí.¿Dices que el código fuente lo copie a la carpeta MVPArticles\Source\ y al .dpr lo ponga en MVPArticles\?
Por eso le di una estudiada intensiva a los patrones antes de meterme al MVP, por un comentario hecho por ella misma (Joanna Carter) en el foro de Embarcadero acerca de los patrones que utiliza el MVP.Así parece, de lo he ojeado a los documentos habla o toca patrones que incluso no he estudiado... como Command e Iterator. Se me hace que el artículo no es para simples inciados en los patrones; en especial si uno no estudió los patrones a que recurre.
Pues yo no utilizo componentes DB-aware, como he dicho en otras ocasiones no me convencen del todo. Si bien es uno de los puentes fuertes de Delphi, desde que toqué el tema OO, el concepto de 3 capas: Interfaz, Lógica, Datos y le metí al tema de patrones como que anda medio descolgado de la teoría de la "independencia de capas" y no me decido totalmente hacia adonde apuntar... aunque mi cabeza tiende más hacia el lado más técnico y purista OO.
Para quien ha utilizado los componentes DB-Ware y no ha implementado clases de negocio, y otras capas intermedias realmente le supondrá un cambio bastante radical.
En los últimos tiempo he desligado la lógica del negocio de la Vista (View) pero lo que no concibo es yo tener que llenar los "Edit" cuando el mismo Delphi me provee un mecanismo para realizar dicha tarea (DB-Aware).
#8
Escrito 10 febrero 2011 - 01:46
Como dice un cómico, y actor, argentino: "cha, gracias".Sí.
En mi caso, es una materia pendiente. Ya veo que le sacaste el máximo provecho... seguramente tu ya tienes medio masticado los patrones Composite, Estrategy, Estate, Template. Yo a eso apenas de oído los toco. El fundamental para comprender el concepto MVC/MVP es Observer... seguro que a este patrón le dedicaste una buena dosis de tu tiempo, y en segunda medida el Command.Por eso le di una estudiada intensiva a los patrones antes de meterme al MVP, por un comentario hecho por ella misma (Joanna Carter) en el foro de Embarcadero acerca de los patrones que utiliza el MVP.
Te envidio, ya quisiera yo lograr avanzar mis estudios sobre patrones.
Yo en mis prácticas y desarrollos evité, casi muy desde el comienzo, los DB-aware. Y recurro a algunos mecanismos inspirados en Observer, Fachade, y Controlator para conseguir vincular la vista con la lógica. Mi mayor fuente de consulta es UML y Patrones, a falta de leer más material. Por ahora no me preocupa demasiado el que recurra a mis "chapuzas" pero reconozco que también me hice esa pregunta (en especial cuando llegué al patrón Observer y lo comparé con el principio de 3 capas).En los últimos tiempo he desligado la lógica del negocio de la Vista (View) pero lo que no concibo es yo tener que llenar los "Edit" cuando el mismo Delphi me provee un mecanismo para realizar dicha tarea (DB-Aware).
Por un lado me parece totalmente lógico, y obvio, conseguir esa independencia. Pero también me he estado diciendo que se está desaprovechando un buen recurso que ofrece Delphi como los son los data-ware.
Quizá una solución "mixta" traiga una respuesta salomónica, pero no se hasta que punto permita absorber cambios y crecer.
Dentro de todo, el diseño de data-ware está bien planteado, y sigue parcialmente los principios de algunos patrones. Como he dicho antes: la forma en como se comunica los dataset con los datasource y éstos a los data-ware está fundada en el concepto del Observer.
No es del todo errado el diseño que han adoptado los ingenieros al elaborar la VCL-ware. Es equilibrada en cuanto a flexibilidad/complejidad.
Aunque cuando nuestros desarrollos son más grandes, y estamos buscando algo más de control sentimos que esto está medio "fuera". Quizá si hubiera nacido desde sus principios con un modelo apegado al MVC/MVP nos toparíamos con algo un tanto diferente.
Saludos,
#9
Escrito 10 febrero 2011 - 05:59
En mi caso, es una materia pendiente. Ya veo que le sacaste el máximo provecho... seguramente tu ya tienes medio masticado los patrones Composite, Estrategy, Estate, Template. Yo a eso apenas de oído los toco. El fundamental para comprender el concepto MVC/MVP es Observer... seguro que a este patrón le dedicaste una buena dosis de tu tiempo, y en segunda medida el Command.
Es como dices, lo tengo medio "masticado" según voy avanzando en la lectura de los artículos de Joanna y ante cualquier duda voy repasando los patrones para que no me quede nada fuera.
En si comprendo la mayoría y entiendo los otros con su posible aplicación (algo confuso lo sé ). El tema de los patrones para mantenerlos vivos se debe estar encima de ellos practicando continuamente y más si el conocimiento se basa en programación estructurada.
En cuanto al patrón Command debes de acompañarlo con el Memento.
Quizá una solución "mixta" traiga una respuesta salomónica, pero no se hasta que punto permita absorber cambios y crecer.
Ese es mi objetivo, buscar un balance entre los dos. Utilizar lo "mejor" de ambos y unirlos hasta el punto de una convivencia pacifica; porque reitero que no dejare de usar los DB-Aware y más después de haber comprado AnyDAC.
#10
Escrito 10 febrero 2011 - 07:20
Asi es, hay que estar constantemente practicándolos hasta agarrarle la mano. Llega un momento en el que, los básicos (los GRASP, y alguno que otro GoF) ya se te salen solo.El tema de los patrones para mantenerlos vivos se debe estar encima de ellos practicando continuamente y más si el conocimiento se basa en programación estructurada.
En mi caso es un tanto diferente, como en la facultad no hicimos tanto pie y base en el paradigma estructurado y saltamos lo más rápido posible hacia OO es que quizá siento que mi cabeza se adaptó al OO (aunque al comienzo me costó descubrirle sentido; Craig me abrió la mente) ya que ni bien toqué Delphi y junto con la lectura de La Cara Oculta y a Tihmothy Budd (¿o era Codd?) era pensar al estilo clases, y más clases.
No es por sacar mi ego pero siento que los patrones Expert, Factory/Method Factory (se lo conoce con ambos nombres), Abstract Factory, Indirection, Singleton, Fachade, Variaciones Protegidas, Acoplamiento y Cohesión son algo obvios.
A mi lo que me dió el simbronazo son Observer, Composite, Estrategy, Command, Proxy (este quizá no tanto) y otros que no recuerdo. Es que la estructura de éstos todavía me le cuesta pensar, destrozarlos y ver su mecanismo pieza a pieza.
Yo lo comparo con la amplia dedicación que le dí a Abstract Factory y cuando comprendí su "misterio" fue como si hubiera encontrado el Santo Grial. Estaba iluminado... Haberlo descompuesto y entender sus piezas me ayudó mucho. No me sucede eso con los anteriores (el que ya más o menos quiso aflojar fue Composite).
Lo escuché nombrar, y leí algo superficial sobre él. Creo que la idea de Memento es de almacenar o guardar el estado completo de un objeto/sistema (aquí se uniría también el patrón Estate) .En cuanto al patrón Command debes de acompañarlo con el Memento.
Lamentablemente UML y Patrones no lo expone, como también le falta Iterator y muchos más.
Tengo que conseguir un libro más completo y específico sobre Patrones. Eso lo dejo para cuanto tenga plata porque los precios de los libros... Yo estaba pensando en concentrarme en los patrones que explica Craig Larman, el libro que considero más urgente adquirir es UML 2.0 para actualizarme. Y Más adelante meterme en el resto de los patrones.
Saludos,