أفضل الممارسات فيما يتعلق بما يلي:LINQ إلى SQL للوصول إلى البيانات

Question

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

المستخدم -> تفاصيل الرسالة <- الرسالة <- فئة الرسالة

يعتبر messageDetail جدول ربط يحتوي أيضًا على علامة IsRead.

يتم تجميع قائمة الرسائل حسب الفئة.لدي عنصري تحكم ListView متداخلين على الصفحة - أحدهما يقوم بإخراج اسم المجموعة، بينما الآخر متداخل بداخله ويرتبط بـMessageDetails ويخرج الرسائل نفسها.في الكود الموجود خلف الصفحة التي تدرج الرسائل، لدي الكود التالي:

protected void MessageListDataSource_Selecting(object sender, LinqDataSourceSelectEventArgs e)
{
    var db = new DataContext();

    // parse the input strings from the web form
    int categoryIDFilter;
    DateTime dateFilter;
    string catFilterString = MessagesCategoryFilter.SelectedValue;
    string dateFilterString = MessagesDateFilter.SelectedValue;
    // TryParse will return default values if parsing is unsuccessful (i.e. if "all" is selected"):
    // DateTime.MinValue for dates, 0 for int
    DateTime.TryParse(dateFilterString, out dateFilter);
    Int32.TryParse(catFilterString, out categoryIDFilter);
    bool showRead = MessagesReadFilter.Checked;

    var messages =
        from detail in db.MessageDetails
        where detail.UserID == (int)Session["UserID"]
        where detail.Message.IsPublished
        where detail.Message.MessageCategoryID == categoryIDFilter || (categoryIDFilter == 0)
        where dateFilter == detail.Message.PublishDate.Value.Date || (dateFilter == DateTime.MinValue)
        // is unread, showRead filter is on, or message was marked read today
        where detail.IsRead == false || showRead || detail.ReadDate.Value.Date == DateTime.Today
        orderby detail.Message.PublishDate descending
        group detail by detail.Message.MessageCategory into categories
        orderby categories.Key.Name
        select new
        {
            MessageCategory = categories.Key,
            MessageDetails = categories.Select(d => d)
        };

    e.Result = messages;
}

هذا الرمز يعمل, ، لكن لصق بيان LINQ ضخم مثل هذا في الكود الخلفي لعنصر تحكم LinqDataSource لا يناسبني.

يبدو أنني مازلت أقوم بترميز الاستعلامات في واجهة المستخدم، والآن أصبح LINQ بدلاً من SQL.ومع ذلك، أشعر أن بناء طبقة أخرى بين فئات L2S وواجهة المستخدم من شأنه أن يقلل من بعض مرونة LINQ.أليس المغزى من ذلك هو تقليل كمية التعليمات البرمجية التي تكتبها لجلب البيانات؟

هل هناك بعض الحلول الوسطى المحتملة التي لا أراها، أم أنني أسيء فهم الطريقة التي من المفترض أن يتم بها استخدام LINQ إلى SQL؟ان النصيحة موضع تقدير كبير.

Answer 1

يجب أن تكون جميع استعلامات LINQ الخاصة بك في ملف فئة منطق الأعمال, ، لا يوجد تغيير عن المنهجيات القديمة مثل ADO.

إذا كنت نقي يجب عليك دائمًا إرجاع قائمة (من T) من الأساليب الخاصة بك في فئة الأعمال، في الواقع، يجب أن يكون سياق البيانات مرئيًا فقط لفئات الأعمال.وبعد ذلك يمكنك التعامل مع القائمة في واجهة المستخدم.

إذا كنت عملي, ، يمكنك إرجاع كائن IQueryable وإجراء بعض المعالجات في واجهة المستخدم.

Answer 2

بغض النظر عن LINQ، أعتقد أن خلط كود العرض التقديمي مع الكود المرتبط بقاعدة البيانات ليس فكرة جيدة.سأقوم بإنشاء طبقة تجريد قاعدة بيانات بسيطة أعلى استعلامات LINQ.في رأيي، LINQ هي مجرد أداة ملائمة، وليس لها تأثير خطير على تصميم التطبيقات التقليدية.