عناصر تحكم نموذج Windows وLINQ؛ماذا يجب أن أعود؟

Question

عند العمل مع عناصر تحكم نموذج Windows وLINQ، هل يوجد "الخيار الأفضل" لكيفية إرجاع طبقة الأعمال الخاصة بك للبيانات؟

أقوم الآن بإرجاع DataTables حتى أتمكن بعد ذلك من تعيين DataSource إلى DataTable الذي تم إرجاعه.هل هناك خيار أفضل؟لماذا؟

public class BLLMatrix
{
    public static DataTable GetMaintItems(int iCat)
    {
        IQueryable<tblCaseNotesMaintItem> tItems = DALMatrix.GetCNTable();
        return
            (tItems.Where(item => item.CategoryID == iCat & item.IsActive).OrderBy(item => item.OrderID).Select(
                item => new { item.ItemID, item.ItemDescription })).CopyLinqToDataTable();
    }

internal static class DALMatrix
{
    internal static MatrixDataContext MatrixDataContext = new MatrixDataContext();

    internal static Table<tblCaseNotesMaintItem> GetCNTable()
    {
        return MatrixDataContext.GetTable<tblCaseNotesMaintItem>();
    }

---

لقد وجدت هذا السؤال المماثل --> فصل المخاوف بشأن Linq To SQL وDTO

Answer 1

شخصيا، أفضل كائنات نقل البيانات، لكن مجموعات البيانات تعمل في قرصة.

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

مجموعات البيانات مفيدة، لكن عدم وجود سلامة تجميع الوقت (ليس في حالة وجود مجموعات بيانات مكتوبة بشدة) بسبب الوصول إلى الحقول المستندة إلى السلسلة يمكن أن يشكل مشكلة.

عادة، هناك أيضا كمية كبيرة من النفقات العامة في مجموعات البيانات المتسلسلة عبر الأسلاك مقارنة بكائن نقل البيانات.

Answer 2

أحب إنشاء فئات نموذجية الخاصة بي بسبب النفقات العامة لمجموعات البيانات. إذا قمت بإرجاع صفيف كائن (أو أي شيء يقوم بتنفيذ واجهة Ilist)، فلا يزال بإمكانك تعيين ذلك يساوي خاصية DataSource لمعظم عناصر ASP.NET.

Answer 3

أنا شخصيا أحب تعيين DataSources عند استخدام الروابط إلى List<YourObject>

Answer 4

أنا أفضل منطق الأعمال لإرجاع مثيل كائن، مثل السيارة أو ICAR أو قائمة (سيارة) السماح لدال بملء الكائن المناسب لك. وبهذه الطريقة تحافظ على فصل واضح بين البيانات و UI.

Answer 5

أحب استخدام DataReaders بدلاً من مجموعات البيانات، وسأستخدم كتلة مكررة في طبقة البيانات لتحويل قارئ البيانات إلى IEnumerable<IDataRecord>.من هناك، لديّ نوع من الخطوة الإضافية بين طبقة الأعمال والبيانات لترجمة IEnumerable إلى ملف IEnumerable<MyBusinessObject>.يجب أن تكون قادرًا على تمرير هذا إلى طبقة العرض التقديمي لربط البيانات أيضًا.

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