2010-08-29 27 views
20

Para mi próxima aplicación web, estoy debatiendo si utilizar Rails 3.x o Sinatra.Rails 3 vs Sinatra

me gustaría utilizar el servidor para proporcionar autenticación de usuario, mensajes de correo electrónico de solicitud disparado, un modelo de datos bastante complejo (detrás de ActiveRecord), y una interfaz de datos JSON con el cliente web. El lado del cliente usará HTML estático, CSS estático, Javascript/jQuery para representar los datos JSON en las vistas. La "política" para la visualización de vistas estará impulsada por el código Javascript y algunos de los datos JSON. No planeo usar ninguna tecnología de vista dinámica como ERB, HAML o RJS.

¿Sería mejor con Sinatra o Rails 3.x?

¿Hay alguna otra pregunta que deba hacer antes de tomar esa decisión?

Respuesta

26

Su modelo de datos es bastante complejo, por lo que imagino que su aplicación deberá manejar un número significativo de reglas comerciales y posibilidades de interacción.

Sinatra está diseñado para manejar arquitecturas de software livianas. Si elige Sinatra, probablemente encontrará problemas de diseño y organización que tendrá que manejar usted mismo. Rails implementa el patrón MVC y puede ayudarte a organizar tu código ofreciendo muchos mecanismos útiles.

Aún puede crear una aplicación web de "pila completa" con Sinatra, pero tendrá que hacer mucho usted mismo, especialmente si la cantidad de funcionalidad que proporcionará es alta (o aumentará). Creo que Rails se adapta naturalmente mejor en arquitecturas más grandes.

PD: ActiveRecord está disponible tanto en Sinatra como en Rails.

+0

Dado que usaría ActiveRecord en cualquier caso, ¿por qué marca la diferencia? Después de todo, ¿no ActiveRecord le permite poner reglas comerciales en la capa del modelo? ¿Qué le daría la pila MVC completa de Rails para reglas comerciales que Sinatra no tiene? –

+2

Por ejemplo, generalmente necesita reglas de validación en su capa de modelo (no proporcionada por AR). Pero el punto es más general: en Rails te colocas en una estructura existente. Usted sigue las convenciones y los patrones que aseguran que su aplicación será fácil de mantener y se escalará bien. Sinatra solo lo ayuda a enrutar y despachar. En una aplicación de gran tamaño, necesitará más que esto: necesitará separar las preocupaciones y los patrones de estructuración. Por supuesto, puede escribir un marco sobre Sinatra para garantizar esto, pero lleva tiempo y tendrá errores (como en todos los programas). (También puedes usar Padrino) – Antoine

0

Es posible que desee echar un vistazo a través del other lightweight Ruby frameworks antes de decidir - la publicación es un poco antigua, pero probablemente valga la pena escanear.

1

Tengo casi la misma tarea que hacer la aplicación de rieles existente que ahora necesita una interfaz json para dispositivos externos (aplicaciones de iPhone y Android). Sugerimos utilizar sinatra-activerecord para que pueda incluir todos sus modelos en su aplicación sinatra. De esta forma, no es necesario que reescriba su lógica comercial.

Cargue sus modelos existentes en su aplicación sinatra de la siguiente manera: conjunto: base de datos, URI.encode ("# {db_settings ['adapter']}: // # {db_settings ['username']} @ # {db_settings [ 'anfitrión']} {/ # db_settings [ 'base de datos']}") requieren './data/models/user.rb'

Y db_settings está cargando su configuración de database.yml (mismo formato que los carriles) usa la joya yaml_db para eso;). De esta forma, su aplicación sinatra puede volver a utilizar todos los modelos e incluso los archivos de configuración de la aplicación Rails.

+0

Si vas a cargar tus modelos de Rails existentes en Sinatra, ¿para qué molestarse? ¿Por qué no usar Rails directamente? ¿Qué ganas yendo con Sinatra? – kakubei

6

Sinatra sería una muy buena opción y creo que sería mejor que los rieles principalmente por una razón. Esto está relacionado con lo que escribió otro usuario "Usted sigue las convenciones y los patrones que garanticen su aplicación va a ser fácil de mantener y escalar bien. Hace

Algunos años hemos desarrollado una bastante grande aplicación en los carriles. Todos nuestros desarrolladores tuvo que hacer una reescritura completa porque el núcleo del riel (leer 37 señales) no quiere que su nueva versión sea compatible con versiones anteriores. En cada actualización, el código se rompería

Así que codificarlo en Rails no asegurará el mantenimiento o la escalabilidad. Todo lo contrario.

De hecho, la escalabilidad será mejor en Sinatra ya que es más liviano y, de todos modos, tendría que usar un pasajero para el despliegue. La comunidad de Sinatra es exagerada y extremadamente útil. No hay prima donnas, gran ego en el mismo grado de Rails. Y esto hace asunto porque la agenda de Rails puede diferir de la suya y podría terminar reescribiendo el código muy pronto. Hay un nuevo libro de O'Reilly sobre Sinatra que creo que merece la pena, ya que está lleno de ejemplos e ideas sobre qué se puede hacer y cómo.

1

¿Por qué usar Rails para algo? ¿Necesitas generadores de plantillas?

Escribir una aplicación con Sinatra o simplemente Pure Rack es tan fácil como en Rails, y obtienes una gran velocidad para todo lo que haces.

Las aplicaciones de Sinatra se pueden organizar de la manera que desee, y es mucho más flexible que Rails, por lo que es la mejor opción, sin importar cuán grande sea la aplicación.

Convertir todo en micro-servicios y agregar middleware personalizado se siente mucho más natural con Sinatra y Rack.

Las personas que dicen que es para aplicaciones o arquitecturas más pequeñas simplemente no lo han usado lo suficiente, no tengo idea de quién comenzó ese mito.