->"chica", es decir de soporte no del tipo Line-of-business Creo que fui más o menos claro, la típica aplicación que sabes que no se va a cambiar de acá a un buen tiempo, capaz yo salgo poco y hago cosas "chicas". Es la aplicación para el kiosco de la tia porota, o la que te piden para el departamento de objetos perdidos...
El 16 de marzo de 2011 14:27, Fabio Maulo <[email protected]> escribió: > que será una applicacción "chica", bah?!?... salgo tan poco... > > 2011/3/16 Walter Poch <[email protected]> > >> 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 >> > > > > -- > 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 > -- 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
