Soy nuevo en RoR asi como en Ruby, no use otros framework de ruby...
pero por lo que conosco respondo a lo que decis. Sin animos de bardear:
On 24/01/2010 16:05, Juan Pedro Fisanotti wrote:
- Flexibilidad: uno de los objetivos que Django se propone es el de no
"interponerse en el camino del desarrollador". Propone hacer las cosas
como el framework las pensó, pero también permite elegir otras formas
de hacerlo sin tener que "romper" nada.
Convention Over Configuration (y no se que tan jodido es cambiar las
cosas en RoR pero asumo que bastante mas... no se en comparacion)
Es muy sencillo utilizar otro
sistema de templates, otro ORM,
Tampoco es dificil usar otra cosa que no sea ActiveRecord y en RoR3 hay
para elegir.
definir otras estructuras de archivos
para la aplicación, etc.
A diferencia, Rails obliga mucho a seguir las convenciones que
propone, deja poca libertad al desarrollador.
CoC-k
- Simplicidad de estructura de una aplicación: algo que me ponía
incómodo en Rails era la interminable cantidad de archivos que poseía
una aplicación web. En Django es completamente lo contrario. No es lo
correcto, pero hasta se podría tener una aplicación con solo 3
archivos, de los cuales 1 viene hecho y no sería necesario
modificarse.
En mi caso esta simplicidad me facilita el desarrollo, ya que no tengo
que estar pasando entre infinidad archivos para completar una tarea
simple.
Si... eso es cierto.. RoR crea mil archivos, muchos de los cuales no le
tenes que brindar mucha atencion, pero luego en el desarrollo igual
prefiero tener varios archivos entes que tener en unos pocos y tener que
estar bajando la pagina y buscando.
- Modelos definidos como clases en un solo lugar, con todas las
declaraciones de los campos juntas y no repartidas en infinidad de
migrations.
DataMapper por lo que estuve viendo es mas simple que activerecord y
esta integrado en RoR3, segun entendi.
A quien le gustan las migrations podrá mencionar la ventaja de llevar
el historial de los cambios sobre los modelos, y poder sincronizar la
base de datos a cualquier momento de ese historial. Bueno, eso mismo
es lo que hace cualquier sistema de versionado de código (svn, git,
hg), ya que los modelos son en definitiva código, y esto incluye poder
sincronizar la base de datos con syncdb, volviéndola a cualquier
estado del historial. Así que no veo necesidad de que el framework
haga versionado de ese código cuando ya tengo algo que lo hace y me
permite además sincronizar la base de datos, y menos cuando ello
implica dificultad para conocer el estado actual de los modelos y
modificarlo.
Bueno.. tenes que instalar algo de versionado y configurarlo si queres
hacer seguimiento de codigo, y tenes que cada vez que haces cambio en el
modelo hacer un push. Las migrations la verdad que no le presto mucha
atencion las hago y las corro, y si quiero ver el estado actual de la
base de datos miro el schema y para las relaciones el modelo. Tal vez
eso es lo feo.. el schema y las relaciones separadas que tiene
ActiveRecord. Por los ejemplos que vi de DataMapper no es asi.
No vi mucho de Rails 3 (solo la noticia y uno que otro comentario),
así que puede que alguna de estas cosas haya cambiado. Ustedes me
corregirán
Es mi punto de vista, con poco conocimiento...
Saludos.
_______________________________________________
Ruby mailing list
[email protected]
http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
