• Redirect Notice –
• RT @elijahmanor: Wat — Funny lightening talk at @codemash by @garybernhardt about language quirks http://t.co/8awxvUGf –
• Windows 8 Storage and Hyper-V – Part 2: VHDX and PowerShell | Hyper-v.nu –
• Elegant Code » Taking Baby Steps with Node.js – Introduction http://t.co/vSGKWtza –
• Windows 8 Storage and Hyper-V – Part 1: Introduction | Hyper-v.nu http://t.co/iNXct54H –
• Continuous Delivery with Deployit, Puppet, JBoss and VMware http://t.co/XsdBYmvK –
• 50 New And Crazy Cool jQuery Plugins From Year 2011 –
• Puppet unit testing like a pro –
• DevOps/CloudOps: The Emerging IT Model | SiliconANGLE –
• Making Your Culture Work with Agile, Kanban & Software Craftsmanship –

Al momento de realizar nuestros mapeos podemos manejar la composición simple manteniendo en una sola tabla las clasesque se relacionan

En este caso “PreInitSearchContext” esta compuesto por un “ContextCreator”.

Traduciendo esto a un Mapeo con FluentNhibernate utilizando “Component()” tendríamos algo así:

Y con esto estaríamos Manteniendo en la misma tabla “pre_init_search_context” ambas clases.

Ahora bien, resulta que existe otra clase que tambien tiene una relación de composición con “ContextCreator”, asi:

Imagino que pensaron en “reutilizar” el código del método Component que tenemos en la clase anterior… y aunque es una opción, estamos generando código repetido y obviamente cayendo en conflictos existenciales relacionados con mantenibilidad.

Es aquí donde “ComponentMap<T>” entra en juego, permitiendonos reutilizar el mapeo, en este caso del “ContextCreator”, entre las clases que sean necesarias

Queda entonces nuestro mapeo asi:

dejando en cada una de las clases solamente:

De esta forma las clases “PreInitSearchContext” y “SearchContext” con sus respectivos mapeos independientes pueden reutilizar el mapeo de “ContextCreator” el cual se traducirá a un par de campos (segun la clase utilizada en el ejemplo) en cada una de las tablas correspondientes.