ruby on rails - sintaxis - Modelos compartidos entre dos aplicaciones de Rails: ¿cuál es la solución ideal para Workflow?
ruby on rails tutorial español (6)
¿Su proyecto tiene suficiente cobertura de código? Si lo hace, trataría de separar la lógica donde tiene sentido, y si se usa un modelo en diferentes proyectos, simplemente elija uno que se adapte mejor y escriba una API además de eso.
Luego, podría usar esa API para acceder a esos modelos (preferiblemente usando algo como ActiveModel) en el otro proyecto. Todavía tendría un CRUD simple, pero toda la lógica del modelo principal se manejaría externamente.
Pero asegúrate de pensar bien antes de dividirlos. Desea mantener su dominio ajustado en cada aplicación que cree fuera del Behemoth que desee dividir.
En cuanto a motores:
He usado Engines para el mismo problema y me ayuda, pero también tuve que cambiar mi Gemfile para apuntar a una ruta local al desarrollar, empujar la gema y luego ponerla en el proyecto actual, que es el comportamiento que estás no aficionado a
Actualmente estoy trabajando en un proyecto de Rails 3 que se divide en cuatro partes:
- El sitio web público
- El sitio web de administración / back-end
- Los modelos
- La API para acceso a datos de terceros
Como los modelos se comparten entre los tres componentes clave, quiero evitar que estén en un proyecto principal, sin embargo, cada parte necesita acceso a los modelos, pero no quiero repetir el código y tener diferentes versiones en todas partes.
Actualmente tengo el código del modelo en una gema, y en el Gemfile de cada proyecto los estoy haciendo referencia con la siguiente línea:
gem "my_models", :path => "../my_models/"
Sin embargo, cuando implemento en nuestros servidores de prueba para que mis compañeros de trabajo evalúen el sistema, necesito extraer los modelos de un repositorio externo, así que canjeo la línea anterior por la siguiente:
gem "my_models", :git => "[email protected]:username/my_models.git"
Esto en sí mismo funciona bien, pero es bastante torpe en términos de ''versiones'' (es decir, necesito reemplazar la versión cada vez que deseo implementar los cambios en los servidores de prueba), cambiar la línea para usar git en lugar de local, y asegúrese de que estoy presionando los archivos correctamente.
Anteriormente estaba usando un submódulo git compartido, pero esto era igual de incómodo.
Prefiero no construir todo en un megaproyecto, ya que estos tienden a volverse monstruosos y difíciles de mantener, y también me gustaría separar las preocupaciones si es posible, por lo que cualquier cambio que realice en el sitio de administración no tiene mucho de posibilidad de afectar los otros componentes; obviamente, los modelos tienen el potencial de causar problemas, pero ese es un riesgo que he considerado y entiendo.
¿Qué sugeriría la gente cuando se trata de algo como esto? ¿O lo estoy haciendo completamente mal?
Algunos antecedentes adicionales:
Esta aplicación es una reescritura de un sitio web existente que siguió el modelo de "agrupar todo en un solo proyecto". Desafortunadamente, hay dos problemas aquí:
- La aplicación estaba mal desarrollada: heredé este proyecto y, cuando lo recogí por primera vez, los tiempos de carga eran de ~ 2 minutos por página con un solo usuario; esto se ha reducido desde entonces, pero todavía presenta problemas
- Actualmente estamos en nuestro límite de capacidad del sitio actual y anticipamos que tendremos que cargar más en los próximos 6 meses; sin embargo, ampliarlo con una aplicación ''todo en uno'' significa que estaremos desperdiciando recursos para escalar. el back-end del sitio que no lo necesita.
Básicamente, hay dos cosas que quiero separar: la interfaz (que es el sitio web público y la API) y la parte de atrás: todo lo que sé sobre el desarrollo de software me dice que combinar todo esto no es una solución ideal (y la historia anterior muestra que dividir estos dos es una buena movida en términos de asegurar el rendimiento del front-end).
Quizás necesito ver esto desde otro ángulo: mantener los modelos en cada proyecto, y en lugar de compartirlos entre proyectos, tenga un subconjunto reducido de funcionalidades para cada área funcional (es decir, el backend necesita saber quién creó una publicación, pero a la parte delantera realmente no le importa eso, así que omita esa lógica cuando lea en el modelo).
Aún tendrá que administrar las ''versiones'' presionando los cambios que necesitan ser probados en un repositorio remoto, pero puede usar la nueva configuración local de Bundler 1.2
http://gembundler.com/man/bundle-config.1.html#LOCAL-GIT-REPOS
De esta forma, recogerá las confirmaciones locales y no tendrá que mantener el cambio de su Gemfile en la implementación.
Mira el subárbol de Git.
Esto puede funcionar para usted..
O
Puedes escribir la tarea de Rake ...
Ejemplo:-
namespace :sync do
desc ''Copy common models and tests from Master''
task :copy do
source_path = ''/home/project/src-path''
dest_path = ''/home/project/dest-path''
# Copy all models & tests
%x{cp #{source_path}/app/models/*.rb #{dest_path}/app/models/}
%x{cp #{source_path}/spec/models/*_spec.rb #{dest_path}/spec/models/}
# Database YML
%x{cp #{source_path}/config/database.yml #{dest_path}/config/database.yml}
end
Vea el enlace a continuación.
http://hiltmon.com/blog/2013/10/14/rails-tricks-sharing-the-model/
Puede crear un motor de montaje que contenga los modelos compartidos y crear una joya. Esto manejará elegantemente los problemas de espaciado entre nombres. Otro aspecto agradable aquí es que puedes compartir tus activos también.
Mire este railscast para más detalles.
Sé que esta no es una solución para su problema particular. Pero realmente te sugiero que combines todos los proyectos en uno solo. Es muy común tener todas estas partes en una sola aplicación y no hay gastos generales. Creo que no hay una solución no incómoda para este problema.
descartar el proyecto de modelos (poner los modelos en una de las otras partes, sugeriría lo que considere "más importante"), poner todos los proyectos en un único repositorio (carpetas de proyecto separadas) y hacer enlaces simbólicos a los modelos / libs / apis / lo que sea
su código está altamente acoplado y, a menudo, necesita realizar cambios en algunos proyectos a la vez (como actualizar modelos y actualizar las API que los usan, etc.)
Una cosa buena de la configuración de repo-symlink único es que sus confirmaciones estarán menos fragmentadas y, por lo general, representarán la implementación completa de características: más fácil rastrear errores, leer el historial y mantener la base de códigos
Además, cuando realiza una implementación, no necesita leer en muchos repositorios: un punto menos de falla ahí mismo.
El proceso de lanzamiento también es más simple con tal modelo ya que la rama mantendrá el alcance de todos los proyectos
hay algunos inconvenientes, como los enlaces simbólicos, no funcionan tan bien en Windows y todo eso, pero para mí funciona a la perfección