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
