Cómo organizar una aplicación Rails

Question

Por primera vez estoy creando una aplicación Rails bastante compleja.

Me gustaría saber cuál es la mejor manera de organizar esa aplicación por carpetas. Hasta ahora, hacía todo bajo una sola aplicación (todos los modelos, controladores, etC), pero leyendo un código fuente abierto me doy cuenta de que ponen todo bajo diferentes aplicaciones.

Como por ejemplo Spree Commerce. Tienen una carpeta general y dentro tienen diferentes aplicaciones (API, núcleo, administrador, etc.). ¿Cómo se hace eso y esa es la mejor manera de hacerlo?

Me gustaría señalarme la mejor manera de hacerlo (un libro, blog, cualquier cosa) para poder entender cómo puedo diseñar mi aplicación para el mantenimiento futuro.

gracias

Answer 1

Como un aparte, creo que el título de su pregunta es un poco confuso. Rails, al usar la convención sobre la configuración, define "cómo organizar una aplicación de Rails". Creo que su pregunta es más bien acerca de cómo arquitecto su aplicación en lugar de cualquier cosa específica de los carriles. Tal vez modificar el título?

Aparte de eso, sin saber más detalles sobre su proyecto, es una pregunta difícil de responder, pero lo probaré.

Todas las aplicaciones deberían comenzar de forma simple, si usted cree (como yo) que debe comenzar construyendo the simplest thing that could possibly work. Dado esto, ya que estás usando Rails, entonces con toda probabilidad lo más simple sería estructurar tu aplicación como una aplicación vanilla Rails 3. Probablemente esto (digo 'probablemente' porque no conozco detalles específicos de la aplicación) le permite tener una versión beta de su aplicación funcionando bastante rápido sin preocuparse por las complejidades que en esta etapa del desarrollo de su proyecto no son un problema

Si necesita crear un XML o API basada en JSON a continuación rieles hace que este really easy utilizando el marco estándar, lo que le permitirá pasar más tiempo pensando en el diseño API de la forma de código, y que es la Diseño de API que es lo más importante para obtener en primer lugar.

De forma similar, su sitio de administración puede formar parte de la misma aplicación solo en un espacio de nombres diferente. Si luego encuentra la línea que desea como una aplicación separada, puede hacer esto (tal vez podría usar la impresionante API que diseñó para facilitar esto), pero ¿por qué molestarse en diseñarlo con esta complejidad añadida (y por lo tanto tiempo de desarrollo extendido?) en primer lugar si no tienes una buena razón para hacerlo?

Una vez que tenga su aplicación en funcionamiento y la gente empiece a usarla, comenzará a hacerse una idea de dónde están los cuellos de botella y dónde podría mejorarse el diseño. En esta etapa, si hay una necesidad, puede comenzar a mover partes de la aplicación a soluciones escalables, como ejecutar su API como un servicio independiente, introducir el almacenamiento en caché, cambiar las tiendas de datos y otras mejoras y optimizaciones.

Incluso si su aplicación es tan exitosa (¡y espero que lo sea!) luego, volver a diseñar su aplicación, mientras que continuar ejecutando el servicio existente sigue siendo completamente posible, como lo ha demostrado Twitter. Solo mantente al Knuth's statement y estarás bien.

En cuanto al material de lectura, es complicado. Para mí, muchos de los XP y los clásicos de desarrollo ágiles me enseñaron muchísimo sobre cómo abordar el diseño de programas y aplicaciones. También verifico this StackOverflow topic para obtener inspiración en el libro.

¡Buena suerte!

Answer 2

en mi humilde opinión, voy a crear proyectos muy complejos como una aplicación. Tengo razones para creer que Spree y Radiant se basan en aplicaciones separadas para que, bajo el pretexto de sus comunidades de código abierto, los contribuyentes puedan contribuir con código fácilmente sin alterar los datos centrales y el funcionamiento central de la aplicación.

De lo contrario, debería estar bien solo compilándolo como una aplicación. Solo mantenlo ordenado.

Answer 3

Spree utiliza Rails 'Railties (Rails::Engines). Railties se introducen en Rails 3 para hacerlo más modular y fácil de extender. Rails 3 en sí es una colección de Railties (ActiveSupport, ActiveModel, ActiveRecord, etc.).

Si está desarrollando una aplicación compleja, le sugiero que dedique un tiempo a planificar su arquitectura. Diseñar una aplicación compleja sin una planificación inicial definitivamente terminaría con una pesadilla de mantenimiento en el futuro. También presenta una enorme curva de aprendizaje para los nuevos miembros del equipo, ralentiza la introducción de nuevas funciones y, por supuesto, la frustración.

De todos modos, no optimice en exceso, pero no se olvide de diseñar su arquitectura para sus necesidades.

Answer 4

aquí es lo que me han mantenido cuerdo durante varios años de desarrollo RoR:

1. que utilizan los motores de Rieles, pero tenga en las mismas código base como la aplicación principal. Aquí es un buen arranque para rieles modulares aplicación: https://github.com/shageman/the_next_big_thing

2. Dondequiera que puedo tratar de reducir el acoplamiento y el uso de la composición para hacer las cosas fácilmente comprobable, reutilizable y fácil de mantener. Esto ayuda a eventualmente extraer el módulo o el motor como una gema separada. La composición se realiza por rutas (montaje), superposición de directorios (activos), inyección de dependencia o configuración.

3. Si no necesito volver a utilizar un motor, lo pongo en la misma base de código que la aplicación principal, que es la unidad de implementación individual. Gracias a eso, no necesito cambiar de proyecto en mi IDE. Mientras que en el entorno de desarrollo, cualquier cambio en el código del motor es recogido instantáneamente por el mecanismo de recarga de Rails.