No hace falta señor.... Gracias por el adjetivo calificativo. :)
Daniel El día 16/05/07, Oscar Onorato <[EMAIL PROTECTED]> escribió:
Mil gracias Diego, Mil disculpas a Daniel que mando una respuestaza. Saludos y gracias El día 16/05/07, Diego Jancic <[EMAIL PROTECTED]> escribió: > > Hola, > Te copio los mails abajo.. los que respondieron fueron Carlos Peix y > Daniel Calvin (por lo menos esos encontre yo) > > Saludos! > > > ---------------------------------------------------------------------------------------- > > Hola Oscar, > > Este es un patron ampliamente usado desde hace tiempo, aunque en DNN > aparece un poquitin especializado y con un nombre nuevo. > > La idea de base se llama Separated Interface y consiste en definir una > interfaz para un servicio determinado y luego proveer implementaciones > de ese servicio. > > Por configuracion y reflection (o Inversion of Control o Dependency > Injection) se determina la clase concreta que prestara el servicio. > > Yo uso bastante esa tecnica para construir Repositories de testeo > hasta que este estabilizado el modelo. Luego construyo los > repositories que acceden a la base de datos y los de testeo los uso > para las pruebas. > > > > ---------------------------------------------------------------------------------------- > Hola Oscar > > Lo vas a encontrar en muchos lados como inversión de control o > Invesion of control. > La idea básica es que las interfaces son menos cambiantes que las > clases, si separas layers o sub sistemas utilizando interfaces logras > mayor adaptabilidad al cambio. > > Basicamente yo lo utilizo para eso y para trabajar con mock objects, > lo utilizo muchísimo para instanciar la capa de servicios de mis > aplicaciones en forma independiente a la capa de transporte, algo en > la capa de datos, y no mucho mas.. > > Tiene mucho sentido en el contexto de utilizar algunos otros patrones: > > principio abierto cerrado > principio de responsabilidad unica > > ( Alta y cohesion y bajo acoplamiento, dicho de otra manera.. cosa + > cosa - ) > Dificil de aplicar si tenés un diseño de dominio complejo y un poco > acoplado. > Muy fácil de implementar si utilizas controladores, clases muy > cohesivas y bajo acoplamiento. > Es como necesitas tener limites y fornteras claramente definidas, alli > es donde lo aplicas con facilidad. > En mi caso siempre esta vinculado a alguna factoria, casi siempre con > algún archivo de configuracion. > Pero esto no siempre es necesario. Podes utilizar factorias estáticas, > no me refiero a static de c#. > > Un abrazo > > Daniel Calvin > >
-- Daniel A. Calvin Cooperator Team Member http://www.cooperator.com.ar Microsoft Certified Professional
