¿Cuál es el mejor enfoque tanto para la modularidad como para la independencia de la plataforma?

Question

Espero que esta pregunta no resulte tan amplia como podría parecer al principio.Estoy diseñando una aplicación de software en mi <sarcasm>voluminoso</sarcasm> tiempo libre.Me gustaría que fuera multiplataforma y modular.En este punto, como todavía estoy en la fase de planificación, puedo elegir prácticamente cualquier idioma y conjunto de herramientas.

Esto hace que las cosas sean más difíciles, no más fáciles, porque aparentemente hay muchas formas de lograr ambos objetivos (modularidad, agnosticismo de plataforma).

Mi premisa básica es que la seguridad, el almacenamiento de datos, la interacción con el sistema operativo y la configuración deben ser manejados por una aplicación "contenedor", pero la mayor parte del resto de funciones se proporcionarán a través de módulos complementarios.Si tuviera que describirlo en un nivel alto (sin revelar completamente mi idea), sería una única aplicación que puede hacer muchos trabajos diferentes, todos dedicados al mismo objetivo (hay muchas cosas dispares que hacer, pero todas los datos tienen que interactuar y estar altamente disponibles).

Esta no es una idea nueva ni particularmente exótica.Sin embargo, me encuentro luchando no tanto con cómo hacerlo (se me ocurren muchas maneras), sino con cuál método es mejor.

Por ejemplo, sé que Eclipse prácticamente encarna lo que estoy describiendo, pero encuentro que las aplicaciones Java en general (y Eclipse no es una excepción) son demasiado grandes y lentas para lo que necesito.Lo mismo ocurre con las aplicaciones de escritorio escritas en Python y Ruby (¡que son lenguajes excelentes!)

No me importa recompilar el código base para diferentes plataformas como ejecutables nativos.Sin embargo, C y C++ tienen sus propios problemas.

Como desarrollador de C#, tengo preferencia por el código administrado.Pero todavía no estoy del todo convencido de Mono (podría estar convencido).

¿Alguien tiene alguna idea/experiencia/marco favorito específico para compartir?

Answer 1

Sólo por citar un ejemplo:para aplicaciones .NET existen CAB (Bloque de aplicaciones compuestas) y Guía de aplicaciones compuestas para WPF.Ambas son principalmente implementaciones de un conjunto de varios patrones de diseño centrados en la modularidad y el acoplamiento flexible entre componentes similar a una arquitectura de complemento:tiene un marco IOC, clases base MVC, un intermediario de eventos débilmente acoplado, carga dinámica de módulos y otras cosas.

Entonces, supongo que ese tipo de infraestructura de patrón es lo que está tratando de encontrar, pero no específicamente para .NET.Pero si ve el CAB como un conjunto de implementaciones de patrones, puede ver que casi todos los lenguajes y plataformas tienen algún tipo de marcos ya integrados o de terceros para patrones individuales.

Entonces mi opinión sería:

1. Estudie (si no está familiarizado con) algunos de esos patrones de diseño.Podrías tomar como ejemplo el marco CAB para la documentación de WPF: Patrones en la biblioteca de aplicaciones compuestas
2. Diseña tu arquitectura pensando en cuál de esos patrones crees que sería útil para lo que quieres lograr. primero sin pensar en implementaciones de patrones o productos específicos.
3. Una vez que haya definido sus 'requisitos arquitectónicos' de manera más específica, busque marcos individuales que ayuden a lograr cada uno de esos patrones/características para el lenguaje que decida usar y cree su propio marco de aplicación basado en ellos.

Estoy de acuerdo en que lo difícil es independizar toda esta plataforma.Realmente no puedo pensar en ninguna otra solución para elegir un lenguaje independiente de plataforma madura como Java.

Answer 2

¿Está planeando una aplicación web o de escritorio?

Todos por aquí parecen pensar que Mono es genial, pero todavía no creo que esté listo para uso industrial, equipararía mono a donde está el vino, gran idea;cuando funciona, funciona bien, y cuando no... bueno, no tienes suerte.mod_mono para Apache tiene muchos fallos y es difícil ejecutarlo correctamente.

Si su objetivo es el escritorio, nada supera el marco eclipse RCP (Rich Client Platform): http://wiki.eclipse.org/index.php/Rich_Client_Platform.

Puede crear Windows, Linux, Mac, todo con el mismo código y todos los componentes de la interfaz de usuario son nativos del sistema operativo.Y RCP gana en modularidad sin lugar a dudas, tiene una arquitectura de complemento que no tiene rival (por lo que he visto)

He trabajado con RCP durante 1,5 años y no sé qué más podría reemplazarlo, es el número uno en su nicho.

Si te opones totalmente a Java, buscaría wxWidgets con Python o C++.

Answer 3

Si desea independencia de plataforma, tendrá que equilibrar el rendimiento y el esfuerzo de desarrollo.C++ puede ser más rápido que Java (esto es discutible FWIW), pero obtendrá la independencia de la plataforma mucho más fácilmente con Java.Python y Ruby están en el mismo barco.

Dudo que .NET sea mucho más rápido que Java (después de todo, ambos son lenguajes VM), pero el gran problema con .NET es la independencia de la plataforma.Mono tiene un objetivo noble y resultados sorprendentemente buenos hasta ahora, pero lo logrará. siempre Estaremos poniéndonos al día con Microsoft en Windows.Es posible que pueda aceptar sus limitaciones, pero aún así no es lo mismo que tener entornos multiplataforma idénticos a los de Java, Python y Ruby.También:las herramientas de desarrollo y soporte de .NET están muy inclinadas hacia Windows, y probablemente siempre lo estarán.

En mi opinión, lo mejor que puedes hacer es apuntar a Java...o, al menos, la JVM.Si no te gusta el lenguaje Java (y como desarrollador de C# supongo que ese no es el caso), entonces al menos tienes opciones como Jython, JRuby y Scala.Con JVM, obtiene muy buena independencia de plataforma, buen rendimiento y acceso a una gran cantidad de bibliotecas y herramientas de soporte.Casi siempre hay una biblioteca, un puerto o una implementación de Java que hará lo que usted necesita.No creo que ninguna otra plataforma tenga la misma cantidad de opciones;Hay un valor real en esa flexibilidad.

En cuanto a la modularidad:se trata más de cómo construyes el software que de qué plataforma utilizas.No sé mucho sobre arquitecturas de complementos como las que usted describe, pero supongo que será posible en prácticamente cualquier plataforma moderna que elija.

Answer 4

Si planeas desarrollar Python, siempre puedes usar pirex para optimizar algunas de las partes más lentas.

Answer 5

Con mi experiencia limitada en Mono, puedo decir que estoy bastante convencido.Es alentador el hecho de que haya un desarrollo activo y un gran esfuerzo continuo para adaptarlo a las especificaciones con las últimas tecnologías .Net.Es increíblemente útil poder utilizar las habilidades .Net existentes en múltiples plataformas.Tuve problemas similares con el rendimiento al intentar realizar algunas tareas básicas en Python + PyGTK; tal vez puedan funcionar en las manos adecuadas, pero es bueno no tener que preocuparme por el rendimiento el 90% del tiempo.

Answer 6

Para aplicaciones de escritorio, escribirlo en un lenguaje interpretado y usar un kit de herramientas de interfaz de usuario multiplataforma como wxWidgets le permitirá avanzar mucho hacia la independencia de la plataforma (solo debe tener cuidado de no utilizar ningún otro módulo que no sea multiplataforma). , usa cosas como Python os.path módulo, en lugar de hacer cosas como config_path = "/home/$USER")

Dicho esto, para hacer un bien aplicación multiplataforma, tendrás que hacer algunas cosas de manera diferente en cada plataforma.

Por ejemplo, OS X es probablemente el más diferente: las preferencias generalmente se almacenan en ~/Library/Prefernces/ como .plists, las UI generalmente se basan en ventanas flotantes, con una única barra de menú acoplada en la parte superior de la pantalla.

Supongo que aquí es donde entra en juego la modularidad.Con el ejemplo de preferencias anterior, podrías tener una clase UserConfig, del cual tiene versiones específicas del sistema operativo.El de Windows almacena los datos de configuración en el archivo apropiado. Application Data carpeta o el registro.El de Mac OS usa archivos .plist en ~/Library/Preferences/, y el de Unix usa ~/.dotfiles.