tutorial software rails ejemplos descargar curso caracteristicas ruby-on-rails

ruby on rails - software - Aplicaciones de dos carriles compartiendo una carpeta modelo



ruby on rails tutorial (7)

¿Por qué no hacerlo de la forma POO, por ejemplo, creando una clase base separada (en un directorio separado) y luego heredándola en ambos proyectos, por lo que las diferencias están en la clase heredada?

Así que tienes

class BaseModel < ActiveRecord::Base

en el subdirectorio "común", y luego tienes

class AdminBaseModel < Common::BaseModel

en el proyecto de administración y

class UserBaseModel < Common::BaseModel

puede que necesites

set_table_name "basemodel"

Así que Rails sabe qué mesa abrir.

Tengo dos aplicaciones de rieles que se ejecutan en la misma base de datos, una que ejecuta el cliente y otra que proporciona una interfaz de administración.

Ambas aplicaciones tienen exactamente los mismos modelos definidos, excepto por un pequeño número de diferencias. Para mí es un fastidio duplicar la gran mayoría de los cambios en los modelos en ambas aplicaciones.

Una forma en que dos aplicaciones pueden usar la misma información del modelo es vincular la carpeta del modelo de una aplicación a otra, pero no puedo hacerlo debido a las pocas diferencias de código (por ejemplo, una validación adicional en el cliente).

¿Existe una forma sencilla de eliminar las diferencias para poder mantener el código común en un solo lugar?


¿Por qué no usar la composición en lugar de la herencia?

Tengo un problema similar: una aplicación de administración y una aplicación pública, con la misma base de datos, y solo algunos métodos específicos en algunos modelos para una aplicación u otra.

Actualmente estoy pensando que podría crear un lugar común con muchos módulos donde pondría mis métodos. Luego incluiría los módulos que necesito en cada aplicación (en modelos, controladores, ayudantes, ...) cuando los necesite. Este lugar podría estar en el directorio lib (actualizado con un submódulo git o svm externo) o en una gema (actualizado con Bundler o una herramienta similar).

Qué piensas sobre esto ?



Sí, vincula el directorio de modelos, pero luego agrega una variable de entorno a tu environment.rb para cada instancia. Entonces sus modelos pueden saber qué instancia lo está utilizando e incluir validaciones adicionales o qué no.

en environment.rb:

APP_INSTANCE = "app1"

en model.rb

validates_length_of :name, :within => 3..100, :if => :is_app_one? def is_app_one? APP_INSTANCE == "app1" end


Solo por curiosidad, ¿por qué no tener una aplicación con dos modos?

Tengo una aplicación que se parece a una de una docena de aplicaciones diferentes, con una marca diferente y una funcionalidad diferente, según la URL en la que ingrese y con quién inicie sesión. Mis usuarios tienen roles y agregué un método a ActiveRecord :: Base que le da el usuario actual. Así puedo hacer cosas como:

MAX_VOLUME = current_user.admin? ? 11 : 10 validates_inclusion_of :volume, :in => 0..MAX_VOLUME # Admins can go to 11!

Y en las vistas, cosas como esta:

<%= render :partial => common_tabs %> <%= render :partial => admin_tabs if @current_user.admin? %>


Trabajo en un proyecto que tiene un problema similar y usamos svn:externals para compartir el código del modelo entre dos aplicaciones.

Básicamente, tiene los modelos diretory en un proyecto svn y usa un externo en el otro proyecto para compartir el código. Puede editar el código en cualquier proyecto y se actualizará cuando ejecute svn up en el otro proyecto.

En lo que respecta a Rails y sus scripts de construcción, los dos directorios de modelos están completamente separados.


svn: los submódulos externos o git son definitivamente el camino a seguir para este tipo de situación.

Por supuesto, querrá poder probarlas en ambas aplicaciones, por lo que también debe compartir las pruebas o especificaciones de su modelo. Pero recuerde que los modelos a menudo dependen de los complementos, por lo que también querrá compartir su carpeta de complementos. Y es probable que desee las mismas gemas y la misma versión de Rails, por lo que su mejor opción es compartir todos los proveedores. Ah, y algunas veces tu código en lib modifica tus modelos, así que querrás compartir eso. Ah, y asegúrese de compartir cualquier configuración personalizada en los archivos del entorno.

Y querrá tener un servidor de integración continuo configurado para ejecutar su suite de prueba en ambas aplicaciones en caso de que los cambios en el nivel de modelo en su aplicación maestra rompan su otra aplicación.

Pero quiero decir, una vez que todo esto está resuelto, svn: externals o git submodules son definitivamente el camino a seguir para este tipo de situación.

Actualización (algunos años después)

Los motores de rieles son probablemente la mejor opción en la actualidad para compartir de manera confiable el código de modelo entre múltiples aplicaciones. Pueden ser gemificados e incluidos en el Gemfile de cada aplicación.