Recopilación de las búsquedas;alternativa al Diccionario

Question

Un TimeSheetActivity clase tiene una colección de Asignaciones.Una Asignación es un objeto de valor que es utilizado por otros objetos en el dominio, así, buscando algo como esto:

public class Allocation : ValueObject
{
    public virtual StaffMember StaffMember { get; private set; }
    public virtual TimeSheetActivity Activity { get; private set; }
    public virtual DateTime EventDate { get ... }
    public virtual TimeQuantity TimeSpent { get ... }
}

Duplicar las asignaciones para la Asignación mismo.EventDate no están permitidos.Así que cuando un cliente intenta hacer una asignación a una actividad, se realiza una comprobación para ver si ya hay una Asignación en la colección para la Asignación mismo.EventDate.Si no, entonces la nueva Asignación se agrega a la colección, pero si es así, la distribución existente es reemplazado por uno nuevo.

Actualmente estoy usando un Diccionario para el mantenimiento de la colección, con la Asignación.EventDate como la clave.Funciona muy bien para el dominio, pero me pregunto si el hecho de que la clave es ya parte del valor no es en sí mismo un 'mal olor'.

También tengo ninguna razón para persistir nada, pero el diccionario de valores.Porque yo estoy usando NHibernate, yo podría necesitar escribir algún tipo personalizado de hacer eso, y me pregunto si eso también es una pista que me debe de usar un tipo diferente de colección.(Esa es también la razón por la que el virtual propiedades en la Asignación de la clase).

La primera alternativa estoy pensando en que sería un HashSet con un dedicado EqualityComparer.

¿Qué te parece?

Saludos, Berryl

Answer 1

Si usa un comparador externo para hacer un HashSet<Allocation>, deberá tener mucho cuidado de no cambiar la fecha sin volver a ingresar el valor en el diccionario. Tiene este problema de cualquier manera, pero se ve exacerbado por la mutabilidad (al menos con Dictionary<,> aún podrá rastrear sus propias claves y valores). Con un valor mutable como parte de la clave, corre el riesgo de no volver a ver el valor ...

Cuando trabajé en sistemas de programación en el pasado, en realidad he usado SortedList<,> para esto, similar, pero útil si generalmente desea los datos en secuencia, y permite la búsqueda binaria si los datos son bastante uniformes.

Answer 2

No creo que el hecho de que la clave sea parte del valor sea necesariamente un problema. En mi experiencia, ese es con frecuencia el caso de los diccionarios. Un HashSet con un comparador de igualdad apropiado ciertamente funcionaría, siempre y cuando nunca haya necesitado llegar al objeto actual con un EventDate particular. Parece algo útil para hacer, potencialmente ...

¿Actualmente solo te preocupa de una manera algo vaga, o tienes una sospecha concreta de cómo esto podría morderte?

Answer 3

El uso de las bibliotecas estándar, no hay mejor solución que yo sepa.Sin embargo, también he sentido este tipo de código para ser un "mal olor", pero es porque de las clases de colección en la BCL y no su código.

No sé por qué MS no crear genérico Conjuntos<TKey, TData> where TData: IKeyed<TKey> o lo que en lugar de los Diccionarios, porque esto permitiría la implementación de estas estructuras de datos donde la clave es la parte de los datos.El KeyValuePair<TKey, TValue>: IKeyed<TKey> acaba de ser ayudante de la estructura de la implementación de esta interfaz y por lo tanto permite crear de forma idéntica diccionario de la funcionalidad, como la tenemos ahora.

También (para continuar con el pequeño rant) me pregunto por qué no añadir la noción de declarativo inmutable tipos y hacer de esta una posible genérico tipo de restricción, ya que esto permitiría asegurarse de que una clave no cambia su hashcode durante el tiempo de ejecución (lo que puede suceder en la actualidad, si uno implementa GetHashCode() y Equals() en algunos objetos mutables).