Omar del Valle Rodríguez - Todos los comentarios

re: DDD: 2- Framework de IoC (Service Pack 1)

Omar del Valle Rodríguez — Thu, 24 Nov 2011 16:32:30 GMT

Gracias por la recopilación Eduard..... ;) yo creo q deberíamos abrir un post solo para eso :)

El tema esta en q hoy en día siempre trabajas con mas de un origen de datos. El principal sigue siendo la base de datos, pero también interactuamos con Google (docs, calendars, contacts), twitter, Facebook, etc. y cada día aparecerán mas...

Si trabajamos con los repositorios y la unidad de trabajo del ORM, estamos cerrandonos a esa fuente de datos, tu arquitectura tendría q variar cuando te pidan recuperar los usuarios de Facebook... :( no?

No seria mas cómodo olvidarnos si los contactos salen de Google, Facebook o nuestra base de datos?

Salu2;

re: DDD: 2- Framework de IoC (Service Pack 1)

Eduard Tomàs i Avellana — Thu, 24 Nov 2011 11:36:03 GMT

Buenas,

Hay un debate abierto sobre si es necesario abstraer IUnitOfWork y tus propios repositorios, o pasar de esas abstracciones y usar directamente el ORM seleccionado (ya sea EF, NH u otro ya que cualquier ORM actual proporciona repositorios y unit of work de serie). Hay posturas en ambos sentidos y personalmente es una decisión que creo que hay valorar en cada caso.

Hace algún tiempo Unai escribió un post relacionado con esto (geeks.ms/.../idbset-iobjectset-como-repositorios-o-tus-propias-abstracciones.aspx).

Alguien que está en contra de dichas abstracciones es Oren Eini (Ayende) como se puede leer en su blog (ayende.com/.../repository-is-the-new-singleton y ayende.com/.../architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer).

Udi Dahan escribió hace tiempo sobre el tema y el prefiere usar Query Objects (www.udidahan.com/.../query-objects-vs-methods-on-a-repository)

Como se puede ver es un tema que da para mucho...

Hay que valorar siempre que ganamos con esas abstracciones y si su uso nos acerca o no a la solución o solo nos añade más complejidad. Unai lo resumió perfectamente en su post cuando dijo "es la responsabilidad de cada uno".

Un saludo!

re: DDD: 2- Framework de IoC (Service Pack 1)

Omar del Valle Rodríguez — Thu, 24 Nov 2011 08:32:26 GMT

Juanma, si te soy sincero, no tengo ni idea... :)

Tengo claro cómo lo hacía antes, y que deseo que esto termine siendo algo parecido a un template que me ayude a tener todo listo cuando inicie un proyecto con este tipo de arquitectura. Por eso, trataré en todo momento de no depender de Framework específicos (NH, Linq2Sql o EF).

Está claro que con IoC ya vimos que no vale la pena. Con el resto de la arquitectura, ya iremos viendo con la ayuda del resto de geeks si vamos o no por buen camino.. :)

Salu2...

re: DDD: 2- Framework de IoC (Service Pack 1)

Juanma — Wed, 23 Nov 2011 13:35:29 GMT

Buenos reflejos, Omar, ahora esto va teniendo una pinta mucho mejor :-)

Viendo este ejemplo de dependencias:

Controller(IService srv) – Service(IRepository repo) – Repository(IUnitofWork uow) – UnitOfWork()

tengo curiosidad por ver cómo vas a montar el UoW.

re: DDD: 2- Framework de IoC (Service Pack 1)

Omar del Valle Rodríguez — Tue, 22 Nov 2011 23:52:30 GMT

@Unai, claro que se permiten comentarios, gracias a eso estamos en este punto :)

Sobre RRR, sí que lo vi... y en la implementación para el caso de servicios WCF se ve claramente em el método ReleaseInstance.

El tema de MVC3 pensé resolverlo usando alguna implementación PerRequest del LifetimeManager de Unity. De todas maneras me lo miro un poco más...Gracias de nuevo.. ;)

@Luis.. gracias por el autobombo.. :P

Salu2 a los dos...

re: DDD: 2- Framework de IoC (Service Pack 1)

Luis Ruiz Pavón — Tue, 22 Nov 2011 23:27:13 GMT

Que gran libro Unai!!! Tengo pendiente hacer una review en el blog.

Por cierto (Autobombo) hace un tiempo que escribí un pequeño artículo sobre IDependencyResolver:

geeks.ms/.../asp-net-mvc-3-por-qu-233-idependencyresolver-no-cumple-con-la-filosof-237-a-de-los-ioc.aspx

Un saludo.

re: DDD: 2- Framework de IoC (Service Pack 1)

Unai — Tue, 22 Nov 2011 23:17:42 GMT

Si me lo permites te voy a hacer otro comentario... Me imagino que en el libro de Mark habrás visto otro patrón RRR ( Register-Resolve-Release). El problema de IDependencyResolver es que no tiene Release ( aunque es cierto que hay una llamada a Dispose si el controlador lo implementa) y por lo tanto a muchos les/nos chilla bastante... por lo que por ahora se sigue haciendo un ControllerFactory en vez de esta implementación...

saludos

Unai

re: DDD: 2- Framework de IoC (parte 2)

Omar del Valle Rodríguez — Mon, 21 Nov 2011 12:15:03 GMT

@Eduard, @Unai...

Gracias por la referencia al blog de Mark y por los comentarios..

Pues el objetivo de todo esto era precisamente lo que Eduard plantea en (2)... :'(

ummm.. preparando Service Pack 1... :)

re: DDD: 2- Framework de IoC (parte 2)

Unai — Mon, 21 Nov 2011 11:18:24 GMT

Estoy totalmente de acuerdo con Eduard, por propia experiencia la abstracción de este concepto no aporta absolutamente nada.

Si tuvieras, algún dia, que cambiar tu framework, sería sencillo teniendo claro cual es tu "Composition Root" o bottstrapper o "last responsible moment" o X, como quieras llamarle.

En cuanto al resolve, tampoco se debería ver como también te hace ver Eduard, con una muy buena referencia hacia el blog de Mark Seemann

Unai

re: DDD: 2- Framework de IoC (parte 2)

Eduard Tomàs i Avellana — Mon, 21 Nov 2011 09:23:45 GMT

Mmmm...

A la espera de ver más...

No termino de ver claro el porque encapsular tu contenedor de IoC en otra clase, ni rl porque de mantenerlo "accesible" a través de la clase Global.

No veo ventaja en abstraerte del contenedor de IoC que uses, si aplicas DI:

1) Tan sólo referencias el controlador de IoC en un solo sitio (el bootstrapper). Por lo que cualquier cambio (de Unity a Windsor p.ej.) supondrá un solo cambio (el bootstrapper). Así pues dado que hay un solo cambio no hay ventaja alguna en abstraerte.

2) Si necesitas acceder explicitamente al contenedor, entiendo que es porque realizas un .Resolve(). Entonces la cuestión es: es service locator un patrón o un antipatrón (blog.ploeh.dk/.../ServiceLocatorIsAnAntiPattern.aspx)??

Por supuesto ya digo, eso son pensamientos a la espera de sucesivos posts!

Saludos!

re: DDD: 2- Framework de IoC (parte 2)

Omar del Valle Rodríguez — Mon, 21 Nov 2011 07:45:36 GMT

Hola Juanma...

Ten en cuenta que el singleton no es para los objetos que creamos con Unity.

El singleton lo utlizamos para mantener en todo momento una referencia a las distintas configuraciones de nuestra aplicación, entre las cuales está el framework de persitencia.

Desde nuestro Singleton (Global) tenemos acceso al idioma por defecto que tendremos, al formato de fecha y hora, y a todo lo que creas que no cambiará durante el ciclo de vida de tu aplicación. Uno de esos elementos que no cambiaría sería el Unity.

No se si con esto entiendas a lo que me refiero, de no ser así, pregunta sin problemas...

Un salu2, y gracias por segir la serie, después de esto empezaremos con la unidad de trabajo (UnitOfWork) y los repositorios...

re: DDD: 2- Framework de IoC (parte 2)

Juanma — Sun, 20 Nov 2011 21:15:31 GMT

Hola,

Estoy siguiendo la serie con curiosidad y me entra una duda.

¿Por qué haces la configuración singleton en lugar de dejar que Unity gestione su ciclo de vida?

re: El Daily Stand-Ups (Scrum) ¿Insuficiente?

Omar del Valle Rodríguez — Tue, 08 Nov 2011 10:15:10 GMT

Manera de reirme la mia con tu comentario.. :) te contacto para hablar mañana :P

re: El Daily Stand-Ups (Scrum) ¿Insuficiente?

Oscar.SS — Thu, 03 Nov 2011 17:21:02 GMT

¿Muerte a los correos?...no paro de sonreír desde que lo he leído :)

Muy buena idea pero me surgen algunas preguntas:

En ocasiones puede que al finalizar el día no se haga check-in, la tarea no está terminada, el código no es estable, épocas de mucha carga (no hay tiempo). ¿Como comprobáis el avance diario en este caso?

Como han comentado antes, si las descripciones de cada item tienen que ser más exhaustivas...¿no "relentiza" esto un poco el desarrollo?. Aunque supongo que todo tiene un precio!

Última pregunta. ¿No tiene el iPhone un botón de devolver llamada?

Excelente...¡como siempre!!

Saludos

re: El Daily Stand-Ups (Scrum) ¿Insuficiente?

Omar del Valle Rodríguez — Thu, 03 Nov 2011 15:05:08 GMT

jajaja.. :P

Pues sí... pero te puedo avanzar que la calidad de los Work items ha mejorado mucho después de tener la herramienta trabajando :)

El informe le llega al PM y a todos los miembros del equipo, por lo que evitas por todos los medios que toda tu actividad durante 8 horas de trabajo solo diga:

- "Arreglar el error"

re: El Daily Stand-Ups (Scrum) ¿Insuficiente?

El Bruno — Thu, 03 Nov 2011 11:39:18 GMT

Jo pues que idea más buena !!!

aunque eso sí, la información que se recoja diariamente para cada usuario depende de la calidad con la que se dé de alta en TFS los elementos de trabajo. :D

Salu2 y a ver con que nos sorprenden

re: resXgen (versión beta)

Jesús Velasco — Sun, 21 Aug 2011 11:16:47 GMT

José Miguel tiene razón:

code.google.com/.../overview.html.

El 1 de diciembre dejará de ser efectiva la API de traducción.

re: resXgen (versión beta)

Sergio — Thu, 28 Jul 2011 12:55:28 GMT

¡Muy bueno!

Me ha gustado, lo utilizaré ;-)

Un saludo.

re: resXgen (versión beta)

Omar del Valle Rodríguez — Thu, 28 Jul 2011 07:25:22 GMT

Hola José...

No sabía lo de google.. o_0 veremos qué pasa..

Gracias por los comentarios.. :)

re: resXgen (versión beta)

José Miguel — Thu, 28 Jul 2011 06:37:53 GMT

Muy interesante la herramienta. Conocía alguna opción mas pesada (la cual debes instalar pese a ser una aplicación web) como ResourceBlender pero esta tiene la ventaja de estar online y no tener que hacer tu propia instalación :).

Aunque precisamente la carencia de ResourceBlender puede ser otra idea: registro de usuarios y mantenimiento de cierta cantidad de datos/proyectos para retomarlos en otros momentos.

Sobre la sugerencia del campo de edición de Jorge: quizás haciendo que aparezca un iconito de un lapiz al lado de un campo cuando pases por encima se entienda que haciendo click (o doble click) se editará el campo.

Por cierto, no estoy completamente seguro si siguen adelante con la idea, pero leí hace unas semanas que Google tiene pensado cerrar la API de traducción debido a la gran carga que le suponía (no se si dejarán la opción de pago por uso, aunque sería lógico). El cierre se producirá el 1 de diciembre.

Saludos,

José Miguel B.