ah... me olvidé... eso nos pasa solo a los albañiles. LOL!!! 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 > > -- 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
