Relaciones
En nuestro sistema, es importante que rastreemos las ventas – específicamente con relación a la fuerza de ventas, de tal forma que podamos proveer algunos reportes básicos. Se nos ha dicho que una venta solo puede pertenecer a un vendedor, y así establecer una relación uno-a-muchos esto es, un agente de ventas puede tener múltiples ventas, y una venta solo puede pertenecer a un único vendedor. En nuestra base de datos, la relación está representada como una columna SalesPersonId en la tabla Sales (llave foránea). En nuestro dominio, la clase SalesPerson tiene una colección de Sales y la clase Sales tiene una propiedad SalesPerson (Referencia).
Ambos extremos de la relación necesitan ser configurados en el archivo de definición de conversiones apropiado, En el extremo de Sales, que se relaciona con una propiedad única, usamos un elemento property glorificado llamado many-to-one;
...
<many-to-one name="SalesPerson"
class="SalesPerson"
column="SalesPersonId"
not-null="true"/>
...
Estamos especificando el nombre de la propiedad, el tipo/clase, y el nombre de la columna que es la llave foránea. También estamos especificando una limitante extra, que es, que cuando agregamos un nuevo objeto Sales, la propiedad SalesPerson no puede ser nula.
El otro lado de la relación, la colección de ventas (Sales) que tiene un vendedor (SalesPerson), es un poco más complicada – básicamente porque la terminología de NHibernate no pertenece a la jerga estándar usada en .NET. Para configurar una colección usamos un elemento de tipo set, list, map, bag o array. Tu primera inclinación puede ser usar una lista, pero NHibernate requiere que tengas una columna que especifique el índice. En otras palabras, el equipo de NHibernate ve una lista como una colección donde el índice es importante, y por lo tanto debe ser especificado. Lo que la mayoría de los desarrolladores de .NET entienden como un list, NHibernate lo llama una bolsa (Bag). Siendo algo confuso tal vez, tanto si utilizas un elemento list o bag, tu tipo de dominio debe ser un IList (o su equivalente genérico IList<T>). Esto es debido a que .NET no cuenta con un objeto IBag, En resumen, para las colecciones que uses comúnmente, utiliza el elemento bag y haz tu propiedad del tipo IList.
La otra opción interesante de colección es el set (conjunto). Un conjunto es una colección que no puede contener duplicados- un escenario común para una aplicación empresarial (aunque rara vez se afirma explícitamente). Extrañamente, .NET no tiene una colección de tipo conjunto, asi que NHibernate usa la interfaz Iesi.Collection.ISet. Existen 4 implementaciones especificas, ListSet que es realmente rápida para colecciones muy pequeñas (10 elementos o menos), SortedSet que puede ser ordenada, HashSet la cual es rápida para colecciones más grandes y HybridSet la cual usa inicialmente un ListSet y automáticamente se cambia así misma a un HashSet conforme crece tu colección.
Para nuestro sistema usaremos un objeto bag (aún cuando no podemos tener ventas duplicadas , es mucho más sencillo por el momento), así que declaramos nuestra colección de Sales como un IList.
private IList<Sale> _sales;
public IList<Sale> Sales
{
get { return _sales;}
}
Y agregamos nuestro elemento <bag> al archivo de definición de conversiones para SalesPersons:
<bag name="Sales" access="field.lowercase-underscore"
table="Sales" inverse="true" cascade="all">
<key column="SalesPersonId" />
<one-to-many class="Sale" />
</bag>
De nuevo, si observas a cada elemento/atributo, no es tan complicado como podría verse al principio. Identificamos el nombre de nuestra propiedad, especifica la estrategia de acceso (no tenemos un configurador, así que hay que indicarle que use el campo con nuestra convención de nombres), la tabla y la columna que contienen la llave foránea, y el tipo/clase de los elementos en la colección.
Tambien hemos configurado el atributo cascade a all lo que significa que cuando nosotros invoquemos la actualización (update) en un objeto del tipo SalesPerson, cualquier cambio que sea hecho a su colección de ventas (Sales) (adiciones, remociones, cambios a las ventas existentes) será automáticamente persistido. La actualización en cascada puede ser un buen ahorrador de tiempo conforme tu sistema crece en complejidad.
a89f253e-07ae-4be8-a805-1adec173a42e|0|.0