flex - descargar - ¿De qué manera la portabilidad de PureMVC beneficia al desarrollador de la aplicación?

adobe flex

Question

Uno de los objetivos declarados del framework PureMVC es evitar las dependencias de la plataforma para que sea portátil. Teniendo en cuenta que debido al idioma y las diferencias API, el código de la aplicación siempre dependerá en gran medida de la plataforma, y ​​que evitar las dependencias de la plataforma hace que el marco reinvente la rueda y / o solo proporcione un conjunto de características del mínimo común denominador, ¿de qué manera la portabilidad? del marco me beneficia como un desarrollador de aplicaciones?

Answer 1

He trabajado con PureMVC. Están tratando de implementar sus cosas en bastantes idiomas. Puede que tengas razón sobre el mínimo común denominador, pero, en general, no es un mal marco, y he visto una muy buena aplicación AS3 en PureMVC.

No creo que estén hablando de portabilidad en términos de portar código real. La idea es que está utilizando una arquitectura MVC generalizada, que puede aplicar a otros proyectos y otros idiomas.

Intentan decir que si te familiarizas con el patrón PureMVC, podrías acceder a una nueva base de código de PureMVC, incluso si se trata de otro idioma, y ​​ya sabrías la configuración del terreno.

También podría decirse que los desarrolladores que desarrollan buenas habilidades de PureMVC es probable que desarrollen buenos hábitos que se traducirán a medida que van del idioma al idioma. Pero, de nuevo, tal vez no ... por las razones que mencionaste.

Answer 2

Hemos estado utilizando PureMVC en dos proyectos ahora y, en mi opinión, el intento de independencia del idioma es una gran carga.

La promesa de saltar directamente en un proyecto porque el marco ya se conoce no me parece relevante si los idiomas ya no son muy similares (C # a Java tendría sentido, como 3 a php no) - Estoy de acuerdo en que es útil han sabido formas de resolver las cosas, pero para eso los patrones ''simples'' son lo suficientemente buenos.

Sin embargo, tampoco estoy de acuerdo con el uso de los diversos patrones que utiliza el proyecto, por lo que nuestra opción de no usarlo en el próximo proyecto podría estar relacionado con ambos problemas, y no solo con el intento de independencia del idioma / plataforma.

Answer 3

PureMVC es la única opción real para los desarrolladores de la plataforma Flash que deciden no utilizar Flex Framework. Para ciertos proyectos, el costo del tamaño de Flex es demasiado caro (¡sucede!).

Me gusta hacer prototipos en Flex y luego extraerlos y reemplazar mis vistas con componentes personalizados cuando la aplicación está casi terminada. PureMVC hace que esto sea realmente fácil de hacer con su patrón Mediator. No estoy seguro de que haya algún otro marco que me permita este flujo de trabajo.

Personalmente, creo que PureMVC fue demasiado lejos con sus objetivos de portabilidad: me gusta el hecho de que funciona con Flash y Flex (por las razones mencionadas anteriormente), pero creo que debería haberse detenido allí, e hizo uso del evento nativo de Flash Player. arquitectura.

Answer 4

La portabilidad de PureMVC lo ayudará cuando migre o vuelva a implementar en otro idioma.

No puedo contar la cantidad de plataformas y lenguajes para los que he escrito código que ahora están extintos y para los cuales, incluso si todavía tuviera el código fuente, no tendría ningún valor y tendré que volver a escribir desde cero hoy, ya que el código generalmente era 100% específico de la plataforma.

Pero no es necesario que todos los códigos de la aplicación dependan en gran medida de la plataforma. Ver los componentes y servicios (los límites de su aplicación) necesariamente serán, pero la lógica de la aplicación que está intercalada entre los límites no tiene que ser necesariamente.

El alcance de PureMVC es bastante estrecho; simplemente para ayudarlo a dividir su código en los tres niveles prohibidos por el metapatrón de MVC. No hay ninguna razón por la que este código deba vincularse profundamente con su plataforma para que sea óptimo.

Cuando llegue el momento de migrar, apreciará que los actores del marco y sus roles, responsabilidades y colaboraciones siguen siendo los mismos. Esto te deja tratar con las diferencias sintácticas del lenguaje, recreando los componentes y servicios de la vista. Al menos no tendrá que volver a diseñar por completo.

Y para el caso de volver a implementar en un idioma diferente, imagine que está tratando de capturar una parte significativa del mercado de dispositivos móviles con su aplicación. El mercado está tan fracturado que tendrás que implementar el mismo programa en 2 o más de Windows Mobile, iPhone, Flash y Java. Seguro que probablemente tendrás equipos separados a cargo de las aplicaciones, pero ¿por qué tener una arquitectura totalmente diferente? Con PureMVC, podría tener una única arquitectura para todas las versiones de su aplicación.

- = Acantilado>

Answer 5

¿Hay ejemplos de personas que usan PureMVC para construir y portar aplicaciones en múltiples plataformas?

Mi empresa está creando una aplicación Flex que quizás necesitemos exportar a otras plataformas:

• Silverlight (probable)
• Móvil (tal vez)
• Escritorio (tal vez, ¡no solo AIR!)
• Televisores (tal vez eventualmente)

Estoy considerando PureMVC como un marco si puede facilitar la transferencia y el mantenimiento. Tengo curiosidad por saber si otras personas han portado una aplicación PureMVC a una plataforma diferente y cuál fue su experiencia con la migración de puertos y luego el desarrollo avanza en paralelo para la aplicación en múltiples plataformas.

Aclamaciones,

Karthik

Answer 6

PureMVC no depende de una plataforma para su funcionamiento interno (Eventos Flash, etc.). Por lo tanto, aunque no hace que portar sea más fácil, por ejemplo, puede ayudarnos simplemente mostrándonos su cara amigable y familiar donde sea que elijamos ;-)