عمليات البحث التحصيل. بديل للقاموس

Question

وهناك فئة TimeSheetActivity لديه مجموعة من المخصصات. وتخصيص هو كائن القيمة التي يتم استخدامها من قبل كائنات أخرى في المجال كذلك، تبحث عن شيء مثل هذا:

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 ... }
}

لا يسمح

ومخصصات مكررة لنفس Allocation.EventDate. حتى عندما يحاول العميل لجعل توزيع لهذا النشاط، يتم إجراء فحص لمعرفة ما إذا كان هناك بالفعل تخصيص في جمع لنفسه Allocation.EventDate. إذا لم يكن كذلك، ثم يتم إضافة تخصيص جديد لجمع، ولكن إذا كان الأمر كذلك، يتم استبدال تخصيص القائمة عن طريق واحدة جديدة.

وأنا حاليا باستخدام قاموس للحفاظ على جمع، مع Allocation.EventDate كمفتاح. أنه يعمل بشكل جيد للمجال ولكن أنا أتساءل عما اذا كان حقيقة أن المفتاح هو بالفعل جزء من القيمة ليست في حد ذاتها "رائحة كريهة".

ولدي أيضا أي سبب للاستمرار أي شيء ولكن القيم القاموس. لأنني أستخدم NHibernate، وأنا قد تحتاج إلى كتابة بعض نوع مخصص نفعل ذلك، وأنا أتساءل إذا كان هذا هو أيضا دليل على أن وأرجو أن تستخدم نوعا مختلفا من المجموعة. (وهذا أيضا سبب خصائص افتراضية في فئة التخصيص).

والبديل الرئيسي أنا أفكر في أن يكون HashSet مع EqualityComparer مخصص.

ما رأيك؟

وابتهاج، Berryl

Answer 1

إذا كنت تستخدم المقارن خارجي للقيام HashSet<Allocation>، هل يجب أن نكون حذرين للغاية ليس لتغيير التاريخ دون إعادة القفل القيمة في القاموس. لديك هذه المشكلة في كلتا الحالتين، ولكن يتفاقم من قبل التحولية (على الأقل مع Dictionary<,> فإنه لا يزال قادرا على تتبع لها مفاتيح والقيم الخاصة). مع قيمة قابلة للتغيير كجزء من المفتاح الذي تخاطر أبدا رؤية القيمة مرة أخرى ...

عند عملت على أنظمة الجدول الزمني في الماضي كنت قد استخدمت فعلا SortedList<,> لهذا - ما شابه ذلك، ولكن من المفيد إذا كنت تريد عموما البيانات في تسلسل، ويسمح بحث ثنائي إذا كانت البيانات موحدة إلى حد ما

Answer 2

وأنا لا أعتقد أن حقيقة أن المفتاح هو جزء من قيمة وبالضرورة مشكلة. في تجربتي وهذا هو الحال بالنسبة للقواميس كثيرا جدا. ومن شأن HashSet مع المقارن المساواة المناسب بالتأكيد العمل، طالما أنك لا حاجة للحصول على الكائن الحالي مع EventDate وجه الخصوص. الذي يبدو وكأنه شيء من المفيد أن تكون قادرة على القيام، وربما ...

هل أنت حاليا فقط مهتمين بطريقة غامضة إلى حد ما، أو هل لديك شكوك ملموسة حول كيفية هذا قد لدغة لك؟

Answer 3

واستخدام المكتبات القياسية، ليس هناك حل أفضل أن أعرف. ومع ذلك، شعرت أيضا هذا النوع من التعليمات البرمجية لابد من "الرائحة الكريهة"، لكنه بسبب جمع الصفوف في BCL وليس التعليمات البرمجية.

وأنا لا أعرف لماذا MS لم تخلق Sets<TKey, TData> where TData: IKeyed<TKey> عام أو نحو ذلك بدلا من قواميس، لأن هذا من شأنه أن يسمح بتنفيذ مثل هذه الهياكل البيانات حيث المفتاح هو جزء من البيانات. ان KeyValuePair<TKey, TValue>: IKeyed<TKey> يكون مجرد هيكل المساعد تنفيذ هذه الواجهة، وبالتالي السماح لخلق وظائف القاموس متطابقة كما لدينا الآن.

وأيضا (لمواصلة التشدق صغير) وأتساءل لماذا لم تقم بإضافة مفهوم أنواع ثابتة التعريفي وجعل هذا ممكنا عام نوع القيد، لأن هذا من شأنه أن يسمح للتأكد من مفتاح لا يغير شفرة التجزئة في أثناء وقت التشغيل (الذي يمكن أن يحدث في الوقت الحالي إذا كان أحد تنفذ GetHashCode() وEquals() على بعض وجوه قابلة للتغيير).