2009/10/4 Emmanuel Oga <[email protected]> > Que interesante que comentes esto... siempre tengo una vocesita en el > fondo de mi mente que me dice que una subclase de activerecord no > debería contener lógica de negocios... Una instancia de ActiveRecord > representa en realidad una fila de una tabla no? Su única > responsabilidad debería ser encontrar cosas guardadas en la db, > instanciar las filas, y guardar las modificaciones. >
Una de las cosas interesantes que trajo Rails fue utilizar un patrón que estaba venido a menos (de hecho, hasta el nombre es despectivo), pero aprovechando bondades de Ruby quedó piola... De hecho, ¡hasta extiende de AR::Base cuando Ruby hace *tan* fácil usar mixins!. La alternativa seria usar clases ActiveRecord solo para todo lo que > tenga que ver con persistencia, y otras clases diferentes para la > lógica de negocios (analizando si es sible que *no* sea > 1ARecord:1BusinessModel). > Esto es muy lindo en la teoría, pero en la práctica, siempre vi monstruosidades cuando quisieron implementarlo (algunos querían llevarlo al extremo: nada, absolutamente nada, que tenga que ver con persistencia en tus objetos de dominio). Ahora, si tus objetos de negocio sí tienen un método "save" (ejemplo) pero lo delegan en lugar de acarrear toda la lógica de cómo generar un fucking string SQL, ahí te compro =D (con AR, todo bien, pero podés hasta incluso acceder estado interno del motor de persistencia :S). En este sentido DataMapper demostró que se puede mantener la hermosa API de AR dejando el comportamiento afuera (y no extendiendo una única clase). En fin, hasta que se me ocurra una alternativa (y/o razones más > contundentes para no hacerlo), lo mas seguro es que siga metiendo mi > lógica de negocios en subclases de ActiveRecord::Base. > Si estás en Rails te diría que no te calientes tanto -- follow the leader =D sabés que todo va a andar bien, y si no innovás mucho va a ser fácil de leer y hasta quizá mantener... tá, siempre hay otra forma de hacer las cosas y siempre todo se puede mejorar -- sólo asegurate de no estar innovando cuando tenés una entrega en poco tiempo (ya tenemos bastantes problemas como para crearnos nuevos). -- nachokb
_______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
