لينك إلى SQL:الإسقاطات وViewModels والاستعلامات غير القابلة للترجمة

Question

يجب أن يتعامل تطبيقي مع كميات كبيرة من البيانات، وحجم التحديد المعتاد هو حوالي 10000 صف.من أجل تحسين الأداء فمن المستحسن فقط تحديد البيانات المطلوبة.

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

عند عرض البيانات فقط (في أغلب الأحيان في جدول)، فهذا ليس ما أريده، أريد تحديد كمية البيانات التي يتم استردادها إلى الحد الأدنى المطلق.

لقد استخدمت حتى الآن الطريقة التالية للحصول على البيانات من مستودعاتي (يظهر أدناه الطريقة التي تقوم بكل السحر داخل المستودع:

private IEnumerable<TResult> GetAllProject<TResult>(Expression<Func<T, TResult>> selector, Expression<Func<T, bool>> predicate)
{
    SetReadContext();
    var query = DataContex.Table<Order>().Where(predicate).Select(selector);

    return query.ToList();
}

بهذه الطريقة أحصل على تعريف النوع للنوع المجهول في الطريقة التي تستدعي المستودع ويمكنني العمل بشفافية مع النوع هناك.

يمكن لكل وحدة تحكم تحديد البيانات التي سيتم تمريرها إلى العرض بالضبط، وهي فعالة للغاية حيث يمكنني التأثير بشكل مباشر على ترتيب الأعمدة وما إلى ذلك.دون الحاجة إلى التعامل مع التحكم في الشبكة في العرض للقيام بذلك من أجلي.لا أحتاج إلى أي LoadOptions في DataContext لأنه يتم تحديد ذلك بناءً على المحدد.

تكمن المشكلة الآن في أنني لا أتحكم في المحدد الذي يتم تمريره إلى المستودع الخاص بي. وقد يحتوي أيضًا على استدعاءات الطريقة وما إلى ذلك.التي ليست قابلة للترجمة.

سؤالي هو:

1. لقد تجنبت حتى الآن إنشاء ViewModels لأنني أخشى حدوث انفجار في النوع.ما هي أفضل طريقة لتنفيذها؟هل يجب أن أقوم بإتاحة أدوات التحديد التي تقوم بالعرض بالنسبة لي؟
2. هل يجب أن أكتب اختبارات الوحدة التي لا تتحقق من أي شيء ولكن إذا تم تنفيذ الاستعلام دون استثناء؟

Answer 1

أنصحك بإنشاء ViewModels بحيث تعمل مع مجموعة معروفة من الفئات، ولا يمثل Type Explosion مصدر قلق حقًا، نظرًا لأنك تستخدم حاليًا أنواعًا مجهولة على أي حال، والتي ربما تكون إدارتها أصعب قليلاً.

إذا كان لديك (عادةً) نموذج ViewModel واحد لكل عرض، فسيصبح نظيفًا بشكل معقول.في بعض الحالات، يمكنك أيضًا مشاركة ViewModels الخاصة بك، على الرغم من أنني أوصي بعدم القيام بذلك لأنه عاجلاً أم آجلاً ينتهي الأمر بأحد المستهلكين إلى الحاجة إلى المزيد من البيانات/الحقول وينتهي الأمر بالآخر باستخدام ViewModel المتضخم.