Si es una aplicación "chica", es decir de soporte no del tipo Line-of-business yo no me enojo poniendo las cosas en el controller, y ni me calentaría en migrarla a otra tecnología a menos que me lo pidan o quiera.
Ahora si, en las apps estratégicas, creo que en el 80% de los casos usaría algo más elaborado. Generalmente eso más elaborado son servicios que encapsulan el negocio, por si el día de mañana migro de tecnología o aparecen sistemas nuevos que consumen ciertas partes, etc... Desde el punto de vista de un peón de albañil ;) El 16 de marzo de 2011 13:29, Diego Mijelshon <[email protected]>escribió: > Confirma lo que decía... en este caso, ese layer adicional agrega valor (la > posibilidad _REAL_ de cambiar de entorno). > > Diego > > > 2011/3/16 Fabio Maulo <[email protected]> > >> No creo que a todos los pragmayicos nos guste testear y ver logica de >> negocio en el Controler. >> Nosotros pasamos desde una app. WebForm (en Azure) a una app. MVC2 (ahora >> MVC3) agregando lo que MVC2 necesitaba pero sin tocar la API del business. >> >> >> 2011/3/16 Walter Poch <[email protected]> >> >>> "El software es para pragmáticos.", lástima que muchos por ahí nos >>> perdemos en el camino =)... llegué al punto de poner este wallpaper de >>> fondo:http://vs2010wallpapers.com/post/1517977545/keep-it-simple , y >>> algunos compañeros me lo copiaron. >>> >>> Saludos, >>> >>> El 16 de marzo de 2011 11:58, Diego Mijelshon >>> <[email protected]>escribió: >>> >>> Coincido con José, y agrego algo similar a lo que comenté en el post de >>>> Oren: el criterio para introducir o retirar layers y abstracciones tiene >>>> que >>>> ver con el valor agregado de los mismos. >>>> Si realmente ayudan a aumentar la productividad y mantenibilidad: a >>>> ponerlos. Si hacen dificil lo sencillo, a sacarlos. >>>> Esto aplica en realidad a todos los artifacts del sistema, desde las >>>> especificaciones de más alto nivel hasta el detalle más pequeño de >>>> implementación. El software es para pragmáticos. >>>> >>>> Diego >>>> >>>> >>>> 2011/3/16 José F. Romaniello <[email protected]> >>>> >>>> >>>>> >>>>> El 16 de marzo de 2011 09:49, Walter Poch <[email protected]>escribió: >>>>> >>>>> Mmmm... lo que propones es usar una "Specification" pero más acotado >>>>>> según veo, que no tenga un filtro sino que directamente devuelva el >>>>>> resultado. >>>>> >>>>> >>>>> Llamalo como quieras... Fabio escribió un post de esto y lo llamo EQO. >>>>> >>>>> >>>>> Si uso NHibernate en el controller entonces la que queda es mandarle un >>>>>> DB de test y hacer test de integración directamente. >>>>>> >>>>> >>>>> Mi opinión sobre esto, es la misma desde hace un año. Esa separación >>>>> entre test de integración y unitario es extremadamente arbitraria e >>>>> inutil. >>>>> Los tests son especificaciones, si para llevar a cabo una >>>>> especificación necesitas: >>>>> -Un *"doble" de test*; sea un mock, stub o hasta un doble que vos >>>>> escribas manualmente (cuando me refiero a doble, es con el significado de >>>>> sustituto) *esta todo bien* >>>>> -Un *objeto real* esta todo bien. >>>>> -Usar *la base de datos*, esta todo bien. >>>>> -Si necesitas *mezclar*, esta todo bien. >>>>> >>>>> La única separación que tiene un poco de utilidad cuando a tests se >>>>> refiere es en tests lentos y rápidos.. Y hasta por ahí nomas. >>>>> >>>>> Vos sos el director y el productor de una película que tiene que >>>>> especificar cierta "escena".. Usa los elemento que sea para que en la >>>>> película quede bien :) >>>>> >>>>> Roy Oshervore dice que un test unitario tiene que ser: >>>>> >>>>> - It should be automated and repeatable. >>>>> - It should be easy to implement. >>>>> - Once it’s written, it should remain for future use. >>>>> - Anyone should be able to run it. >>>>> - It should run at the push of a button. >>>>> - It should run quickly. >>>>> >>>>> No dice nunca; "tiene que estar basado en dobles" tampoco dice "no >>>>> tiene que usar la base de datos". >>>>> >>>>> >>>>> Saco esto, porque he visto Rails, y ellos no usan tanta parafernalia >>>>>> para sus controllers y aplicaciones. De las aplicaciones que estoy >>>>>> haciendo >>>>>> creo que una el Home Banking merece una arquitectura grande, las demás >>>>>> como >>>>>> dice Ayende, es complicar las cosas. >>>>> >>>>> >>>>> Si, la gente de Rails se rie cuando escuchan la palabra "enterprise" en >>>>> alguna conversación... >>>>> Creo que todo tiene mucho que ver con como se construye la arquitectura >>>>> de un sistema, lo mejor sería que el diseño a grandes rasgos evolucione >>>>> desde tests y refactorizaciones. >>>>> Aunque también estos es discutible, hay quienes van a venir a decir "yo >>>>> hice 40 aplicaciones mas o menos parecidas, y se que tengo que tener un >>>>> proyecto de dominio y otro de repositorios" >>>>> >>>>> -- >>>>> Para escribir al Grupo, hágalo a esta dirección: >>>>> [email protected] >>>>> Para más, visite: http://groups.google.com/group/NHibernate-Hispano >>>>> >>>> >>>> -- >>>> Para escribir al Grupo, hágalo a esta dirección: >>>> [email protected] >>>> Para más, visite: http://groups.google.com/group/NHibernate-Hispano >>>> >>> >>> >>> >>> -- >>> Saludos, >>> >>> Walter G. Poch >>> Sr. .Net Developer >>> -------------------------------------------- >>> Cell: +54 (9 341) 3353273 >>> [email protected] >>> >>> -- >>> Para escribir al Grupo, hágalo a esta dirección: >>> [email protected] >>> Para más, visite: http://groups.google.com/group/NHibernate-Hispano >>> >> >> >> >> -- >> Fabio Maulo >> >> -- >> Para escribir al Grupo, hágalo a esta dirección: >> [email protected] >> Para más, visite: http://groups.google.com/group/NHibernate-Hispano >> > > -- > Para escribir al Grupo, hágalo a esta dirección: > [email protected] > Para más, visite: http://groups.google.com/group/NHibernate-Hispano > -- Saludos, Walter G. Poch Sr. .Net Developer -------------------------------------------- Cell: +54 (9 341) 3353273 [email protected] -- Para escribir al Grupo, hágalo a esta dirección: [email protected] Para más, visite: http://groups.google.com/group/NHibernate-Hispano
