python - restful - ¿Cómo diseñar una aplicación de forma modular?
flask python español (5)
Estoy buscando punteros, sugerencias, enlaces, advertencias, ideas e incluso relatos anecdóticos sobre "cómo diseñar una aplicación de forma modular" . Voy a utilizar python para este proyecto, pero el consejo no necesariamente tiene que referirse a este lenguaje, aunque solo estoy dispuesto a implementar un diseño basado en OOP.
Aquí hay un contexto para entender de dónde vengo y lo que estoy tratando de lograr ...
Mi proyecto será una pequeña aplicación que consumirá servicios web y mostrará los resultados de varias maneras, incluyendo:
- notificación emergente que contiene solo el resultado de la llamada
- pestaña en la ventana principal de la aplicación con gráficos trazados a partir de datos en bruto recuperados
- búfer de mensajes (visible en domand) donde se acumularán los resultados de varios servicios
La aplicación se lanzará como software gratuito (en el momento de la voz), y por este motivo me gustaría que otros desarrolladores puedan escribir plugins / módulos que amplíen la funcionalidad de la aplicación principal sin necesidad de cambiar la funcionalidad. código del núcleo
En este momento, los complementos deberían esencialmente permitir que un desarrollador active un nuevo servicio web, definiendo el proveedor, la manipulación de los datos (si corresponde) y la forma en que los datos se presentarán al usuario .
Tengo una amplia experiencia en el desarrollo con drupal que tiene un potente enfoque modular, pero que también sigue un diseño no orientado a objetos, por lo que sospecho que para python, el diseño de drupal podría no ser la solución óptima.
Si esto tiene alguna importancia, el núcleo se desarrollará de forma nativa para GNU / Linux.
¡Gracias de antemano por su tiempo!
Bueno, probablemente el primer lugar para comenzar es sentarse y descubrir qué podría necesitar el complemento para cumplir su propósito.
Usted querría considerar dos aspectos principales en su diseño.
- ¿Cómo aprobará / enviará su marco las respuestas del complemento?
- ¿Qué clases o módulos de ayuda podrían ser buenos para proporcionar?
Y probablemente también, ya que esto suena como un proyecto de aprendizaje.
- ¿Qué quiere escribir usted mismo, y qué es lo que está feliz de elegir de una biblioteca existente?
También recomendaría desarrollar algunos complementos básicos al diseñar la API. La experiencia de tener que usar realmente lo que diseñas te permitirá ver dónde un enfoque determinado puede hacer las cosas más difíciles de lo que deberían ser.
Como entregará algunas funciones básicas con su aplicación, asegúrese de codificar la parte que debería ser extensible / reemplazable ya como complemento. Entonces, será mejor que tengas una idea de cómo debería verse tu API.
Y para demostrar que la API es buena, debes escribir un segundo y un tercer complemento, porque entonces descubrirás que hiciste muchas suposiciones al escribir el primero. Normalmente, las cosas se aclaran un poco después de realizar este segundo y tercer paso.
Ahora, debes escribir un complemento más, porque los últimos complementos que escribiste se parecen al primero en tipo, datos de entrada y presentación (quizás otro servicio web meteorológico). Elija algo totalmente diferente, con datos absolutamente diferentes, y verá que su API sigue siendo demasiado personalizada. (¡Si no hiciste un buen trabajo!)
Mira en el patrón de oyente-suscriptor. Tarde o temprano, su aplicación será lo suficientemente compleja como para que necesite implementar devoluciones de llamada. Cuando llegue a ese límite, use el oyente-suscriptor (hay una implementación en wxPython).
Por ejemplo, varios módulos querrán ver los nuevos datos de varios feeds. Es posible que los módulos que se enlazan entre sí quieran actualizarse, según los nuevos datos.
Trate de mantener las cosas ligeramente acopladas, y use las interfaces generosamente para ayudar.
Comenzaría el diseño con la Separación de Preocupaciones . Las principales capas arquitectónicas son:
- Dominio del problema (también conocido como Motor, Back-end): las clases de dominio, que realizan todo el trabajo real, tienen conocimiento del dominio que implementa el comportamiento del dominio
- Persistencia: gestión de almacenamiento para clases de dominio, capa de base de datos / sistema de archivos
- Interfaz de usuario: la GUI, que habla con las clases de dominio
- Interfaces del sistema: hablar con otros sistemas, por ejemplo. redes, servicios web
Las clases de dominio hacen el trabajo, pero no saben acerca de la interfaz de usuario. La capa de persistencia conoce las clases de dominio, lo suficiente para guardar / cargar según sea necesario. La capa de interfaz del sistema aleja a los sistemas externos, lo que le permite conectar un simulador por detrás durante la prueba. La interfaz de usuario debería utilizar idealmente MVC, para una máxima flexibilidad.
Sin poner un punto demasiado fino en él, uno normalmente no vería a Drupal como un ejemplo de buen diseño arquitectónico. Ha crecido de manera bastante orgánica, y ha habido muchos cambios en el diseño, como lo demuestra la ruptura regular de los complementos en las actualizaciones del sistema.
También me gustaría repetir lo que dijo MicSim, en relación con el diseño cuidadoso de la interfaz del complemento y la escritura de múltiples complementos diferentes para ejercerlo. Esta es la única manera de desarrollar realmente los problemas de cómo interactúan la aplicación y los complementos.
- diseñe la api para su aplicación, cuidadosamente ( Cómo diseñar una buena API y por qué importa )
- haga todo, que podría usarse independientemente en un módulo, luego agrupe y construya partes más grandes a partir de las partes simples (KISS)
- no te repitas (SECO)
- escriba / publique documentación corta con frecuencia, para usted y otros (mantra de código abierto) ...