الرئيسية
أحدث الصور
السلام عليكــم ورحمـة الله وبركاتــة ،،
ماهو LINQ :
Language Integrated Query, هذه التقنية التي يجري تطويرهاحاليا بواسطة Anders Hejlsberg كبير مهندسي التخطيط (في بورلاند سابقا) وفي مايكروسوفت حاليا والتي ربما تكون الميزة الأهم التي ستوجد في لغات البرمجة قريبا (في C# 3.0 حسب مايعتقد , وتم الحديث عنه من أجل Delphi كذلك , ومن دون شك سيوجد في لغات أخرى ) .
الفكرة الأساسية خلف LINQ أنه توجد فجوة كبيرة بين منطق البرنامج المكتوب بلغة برمجة وبين البيانات التي تتعامل معه , فكلما زادت كمية البيانات التي عليك معالجتها , كلما أصبحت أبعد منطقيا وفيزيائيا بالنسبة لبرنامجك .
خذ على سبيل المثال تقنيات قواعد البيانات التي تنظم عملية تخزين واسترداد المعلومات , تعتمد تقنيات قواعد البيانت هذه بشكل كلي على تعابير SQL , والتي هي عبارة عن صيغ وعبارات تشكل لغة بسيطة وقياسية لتنظيم عملية التعامل مع البيانات بين المستخدم (أو التطبيق) من جهة و برنامج إدارة قاعدة البيانات من جهة أخرى .
الجميل ب sql أنك تعطيها شكل الخرج الذي تريدة وهي تخرجه لك دون أن تشغلك بكيفية القيام بذلك .
تأمل ذلك :
كودSelect name,hire_date,salary from employee
Where salary > 5000 order by name
أنك تعطيها الحقول التي تريد أخراجها , وشرط إخراج هذه الحقول (الراتب أكبر من قيمة محددة) , وترتيب هذه البيانات , أي تعطيها تصور عن الخرج الذي تريدة .. وهي تنفذة لك بدقة , ومن دون أن تضطر للدخول في تفاصيل كيفية القيام بذلك ...
أنت لاتحدد لها طريقة القيام بذلك فهي مسؤولة عن أعادة المعلومات التي تطلبها بالشكل المحدد وبالأداء الأكفأ ...
حسنا هذا شيء جميل جدا .. ولكن أين تكمن المشاكل ؟
تكمن المشكلة برأيي أننا عندما نمرر تعبير sql من تطبيق مبني على أي لغة برمجة كانت فيجب تمريرة على شكل سلسلة نصية من المحارف Strings ليتولى مخدم قاعدة البيانات تفسيرة في زمن التشغيل لحظة طلب المعلومات لإعادة المعلومة اللازمة ..
ولنفرض أن عبارة الsql كان فيها خطأ ما , باسم جدول , باسم حقل ,بتعبير , بكلمة غير محجوزة .. أي خطأ
أن هذا الخطأ لن يتم اكتشافة بسهولة وعلى الغالب يجب الإنتظار حتى زمن التشغيل وحتى طلب هذا الاستعلام من المخدم حتى نعرف أن الاستعلام خاطيء وذلك بظهور رسالة من المخدم تحوي أرقام ورموز تدل على نوعية الخطأ ورقمة ..
الكثير من لغات البرمجة لديها قوة تنميط رائعة , ولديها صرامة نحوية واضحة تأخذ بيد المبرمج بعيدا عن الأخطاء , فمن السهل كتابة تطبيقات كبيرة فاعله في لغة برمجة عالية المستوى تحترم قواعد التحويل وخصائص الأنماط , وتقدم تقنيات وقت تصميم كافية لتسهيل توقع استجابة البرنامج في زمن التشغيل ... والأن كل ذلك .. كله , مع الأنماط الصارمة والأغراض , والأستدعاءات , وأكواد الكومبايلر المحسنة لن تفيدك أي شيء عندما ترسل الأستعلام كعبارة نصية بين إشارتي اقتباس لإنه لن يتم الحكم عليه والتعامل معه حتى لحظة إرسالة إلى برنامج إدارة قاعدة البيانات ,
ببساطة SQL رائعة جدا , ولكن توجد فجوة كبيرة بينها وبين منطق برنامجك في العمل , إنها منعزلة وخارج السياق ولا يمكنك أن تدمجها مع البرنامج بالطريقة الكافية للإستفادة من مزايا لغة البرمجة التقليدية كقوة الأنماط او المنقح أو غيرها من مئات التقنيات المعتادة والمهمة في عالم البرمجة اليوم ..
وهنا يكمن دور LINQ ..
ردم الفجوة بين منطق البرنامج القائم لديك وبين تقنيات معالجة كميات كبيرة من البيانات (ولنقل sql كمثال) والتزويد بحل محلي مدمج مع لغة البرمجة يتولى عملية التعامل مع التخزين الكبير للمعطيات .
هكذا حل سيكون بالتأكيد متوافق مع نحو (Syntax ) لغة البرمجة , فهو بالنهاية نوع جديد من التعليمات يتعلم علية المبرمج بسهولة بالغة لكي يعفية من الغوص في تفاصيل نحو لغات وتقنيات أخرى , لاتنسى أنك مضطر لتعلم النحو الخاص بsql مثلا عند الرغية بإجراء أي برنامج يحتك مع قواعد بيانات كبيرة الحجم مخزنة على وسيط محلي أو خارجي .
هذا ليس هجوم على تقنيات معالجة البيانات الحالية او هجوم على sql نفسها
Sql واضحة ومعبرة بقوة وتلبي الهدف الذي خلقت من أجلة بشكل أمثلي
ولكن تكمن المشكلة أن sql دائما بعيدة وغريبة عن برنامجك , حيث تشعر وكأن البرنامج أصبح مقسوم إلى جزأين منطقيين : مستوى التطبيق , ومستوى قاعدة البيانات الذي يعبر عنه باستعلامات الsql ... يمكن التقريب بين هذين الجزأين باستخدام بعض التقنيات مثل stored procedures والتي تستطيع نقريب الكود اكثر من البيانات ..ولكن لازال الوضع قاصرا وعليك القيام بالكثير للحصول على نتائج مثالية باستخدام هذا التصور .
عمليا بإمكاننا القول أنه يوجد إنقطاع في دورة حيات التطبيقات الحالية وهذا الإنقطاع في المشروع يمثل فرصة سانحة للإخطاء البشرية كما أنه سضيع سلسلة التنفيذ .
ماذا لو تمكنت من إنجاز تسلسل منطقي محدد على بيانات ضخمة من داخل لغة البرمجة التي تعمل عليها , باستخدام وسائل معتادة كالأغراض , أنماط المعطيات ,المتحولات والتقنيات الأخرى في شفرتك الطبيعية من دون الحاجة لتقوم بعملية الوصل السابقة .
هذا مايهدف إلية LINQ
LINQ سيكون دمج بين نحو لغة برمجة ما syntax , وبين البنية التحتية لمنصة .NET لدعم مقدرات استعلامية مشابه للsql من ضمن لغة البرمجة نفسها , مما يتيح التعامل مع البيانات في مجال لغة البرمجة نفسها وليس في مجال تقنيات الوصول للبيانات .
وهنا الجزء المثير من القصة
LINQ مستقل عن SQL , فاستعلامات LINQ تشغل على بنية معطيات معرفة تستطيع تمثيل النمط IENumerable وهذا يشمل قواعد البيانات وغيرها .
تخيل أنك تستطيع أن تقوم باستعلامات ومشاهد معقدة للبيات المخزنة ضمن برنامجك في اللوائح , المجموعات ,الأنماط التعدادية , وحتى المصفوفات كذلك ..
تريد ان ترتب مصفوفة من الأعداد الصحيحة ؟ إذا قم بانشاء استعلام ضمني بعبارة شبيهه بـ order by .
ستكسب بهذه الطريقه أكثر بكثير من كل ميزات الsql التقليدية , حيث أصبحت تتعامل مع أنواع أكثر من البيانات , وأغلقت الفجوة بين البيانات والكود , واستخدمت نحو قياسي أكثر حسب كل لغة برمجة ... والمزيد
هل سيتم الإستغناء عن sql ..
مستحيل !!
سيتم الإعتماد على sql من قبل LINQ نفسه في كثير من الأحيان .. فالكثير من قواعد البيانات مثلا لديها مزايا استعلامات خاصة بها تعتمد على طريقة تخزينها للبيانات ضمنها وطريقتها بالتعامل مع هذه البيانات ..
الحل كما هو متوقع أن الطرف النهائي سيأخذ استعلام LINQ ويولد منه عبارة sql مناسبة لها ليقوم برنامج إدارة قاعدة البيانات بتولي استجابة لحظية لها .
وبقية الانماط التي يتعامل معها LINQ (المصفوفات مثلا ) طرائق خاصة بكل منها لسنا بصدد ذكرها هنا .
مايجعل الموضوع فعالا وثوريا أنه يمكن تضمين هذه الأنماط وسائل خاصة لاسترجاع المعلومات المشروط بشكل داخلي (سريع وكفوء ومتخصص) حيث يمكن أن يتولى الصنف إرجاع المعلومات التي طلبت منه من الخارج وفق ما يناسبة في الداخل .. ربما يعتبر هذا تفكير مستقبلي ولكني أعتقد أنه سيكون وارد ومدروس أمام مصنعي LINQ ..
هكذا تقنية ستسهل بشكل كبير تصنيع تقنيات حوسبة متفرعة ضمن أدوات برمجية بسيطة يستطيع استخدامها المطورون يوميا بسهولة فائقة وقوة جامحة ..
هل LINQ متكامل
لا أعرف فلم تصدر معلومات كافية عن LINQ بعد .. ولكن عادة هذا النوع من التقنيات التي تزيد من محلية وخصخصة الأدوات المتعلقة باسترجاع البيانات يعمل بنمط Binding أو bounded بهدف القيام بعملية مزامنة آلية بين ما أملكة بين يدي وبين البيانات المخزنة في وسيط بعيد , لإن الأحداث المقدوحة ستنتظر استجابة محددة من النظام ,, وهذا موضوع كرية ومعقد قليلا ولابد ان يسبب عدد من المشاكل
تخيل لو تم طلب استعلام sql من الخارج , مكونات الأخراج تبقى في حالة إنتظار لإنها تعمل في نمط binding مما يجعل حالتها الآنية متعلقة بعودة الاستجابة من قاعدة االبيانت إليها , ربما تطول العملية ويتسبب ذلك باشكالية ما , مثلا جمود الواجهة , أو زيادة كلفة خوارزميات الإضافة والتحديث , أو عدم معالجة كافية لتصرف المستخدم في وقت التنفيذ الخ ..
بعض التقنيات الجديدة كمفهوم ECO الذي طرح مع Delphi2005 Studio استطاع التغلب على ذلك بفاعلية مما جعلة تقنية ثورية وسبب له سيط كبير بين أوساط أخصائيي التقنية , حيث نجح ECO بالتقريب بين أفكار هندسة البرمجيات (مخططات UML مثلا) وبين منطق كتابة البرنامج , مما قرب بين النظرية والتطبيق , وقلل مستوى الخطأ بالتكويد إلى درجة منخفضة , جديد ECO هو أنك تكتب برنامجا تم التفكير فيه بطريقة هندسة البرمجيات , وتستخدم مخططات uml وأفكار تصورية لتمثيل الإستجابة المتعلقة بادخال/استرجاع البيانات من قاعدة بيانات مثلا , أو التعامل مع تطبيق ويب أو غيرها ..
ولكن السؤال هل يمكن ل LINQ أن ينجح بهكذا تحدي رغم الإ‘ختلاف الكبير بين الأثنين وبين ظروف كل منهما .. لنترك ذلك للزمن .
لنرى مثلا كم ستكون كمية الخطر المتوقع بمثال بسيط, تطبيقك متصل مع قاعدة البيانات وحصل تغيير على أسم احد الجداول أو الحقول أو نوع بيانات هذا الحقل ,, الاستجابة المتوقعة هي للأسف .... أنهيار البرنامج ..
على الأقل بالنسبة للمدى المنظور لايبدو ان LINQ وجد حل فعلي لهذه المشكلة بعد .
ماعدا ذلك اظن أن المشكلة الوحيدة ستكون أن Linq على الغالب سيجر تعقيدات إنشاء الاستعلام إلى برنامجك , أي أن ضريبة استخدام أستعلام مضمن لابد من دفعها بالقلق حول تفاصيل إنشاء الاستعلام التي ربما لم تكن مهتم بها قبلاً .
من سيدعم LINQ ؟
على المدى المنظور يتوقع أن تدعمة مبدأيا لغات البرمجة التي تستطيع العمل فوق منصة .NET مثل C# , Delphi.NET وغيرها ..
وإذا أصبح LINQ مفهوم برمجي , أو تقنية قياسيه قد ينجر الحبل لدعم اجيال أخرى من اللغات .
المصدر
ماهو LINQ :
Language Integrated Query, هذه التقنية التي يجري تطويرهاحاليا بواسطة Anders Hejlsberg كبير مهندسي التخطيط (في بورلاند سابقا) وفي مايكروسوفت حاليا والتي ربما تكون الميزة الأهم التي ستوجد في لغات البرمجة قريبا (في C# 3.0 حسب مايعتقد , وتم الحديث عنه من أجل Delphi كذلك , ومن دون شك سيوجد في لغات أخرى ) .
الفكرة الأساسية خلف LINQ أنه توجد فجوة كبيرة بين منطق البرنامج المكتوب بلغة برمجة وبين البيانات التي تتعامل معه , فكلما زادت كمية البيانات التي عليك معالجتها , كلما أصبحت أبعد منطقيا وفيزيائيا بالنسبة لبرنامجك .
خذ على سبيل المثال تقنيات قواعد البيانات التي تنظم عملية تخزين واسترداد المعلومات , تعتمد تقنيات قواعد البيانت هذه بشكل كلي على تعابير SQL , والتي هي عبارة عن صيغ وعبارات تشكل لغة بسيطة وقياسية لتنظيم عملية التعامل مع البيانات بين المستخدم (أو التطبيق) من جهة و برنامج إدارة قاعدة البيانات من جهة أخرى .
الجميل ب sql أنك تعطيها شكل الخرج الذي تريدة وهي تخرجه لك دون أن تشغلك بكيفية القيام بذلك .
تأمل ذلك :
كودSelect name,hire_date,salary from employee
Where salary > 5000 order by name
أنك تعطيها الحقول التي تريد أخراجها , وشرط إخراج هذه الحقول (الراتب أكبر من قيمة محددة) , وترتيب هذه البيانات , أي تعطيها تصور عن الخرج الذي تريدة .. وهي تنفذة لك بدقة , ومن دون أن تضطر للدخول في تفاصيل كيفية القيام بذلك ...
أنت لاتحدد لها طريقة القيام بذلك فهي مسؤولة عن أعادة المعلومات التي تطلبها بالشكل المحدد وبالأداء الأكفأ ...
حسنا هذا شيء جميل جدا .. ولكن أين تكمن المشاكل ؟
تكمن المشكلة برأيي أننا عندما نمرر تعبير sql من تطبيق مبني على أي لغة برمجة كانت فيجب تمريرة على شكل سلسلة نصية من المحارف Strings ليتولى مخدم قاعدة البيانات تفسيرة في زمن التشغيل لحظة طلب المعلومات لإعادة المعلومة اللازمة ..
ولنفرض أن عبارة الsql كان فيها خطأ ما , باسم جدول , باسم حقل ,بتعبير , بكلمة غير محجوزة .. أي خطأ
أن هذا الخطأ لن يتم اكتشافة بسهولة وعلى الغالب يجب الإنتظار حتى زمن التشغيل وحتى طلب هذا الاستعلام من المخدم حتى نعرف أن الاستعلام خاطيء وذلك بظهور رسالة من المخدم تحوي أرقام ورموز تدل على نوعية الخطأ ورقمة ..
الكثير من لغات البرمجة لديها قوة تنميط رائعة , ولديها صرامة نحوية واضحة تأخذ بيد المبرمج بعيدا عن الأخطاء , فمن السهل كتابة تطبيقات كبيرة فاعله في لغة برمجة عالية المستوى تحترم قواعد التحويل وخصائص الأنماط , وتقدم تقنيات وقت تصميم كافية لتسهيل توقع استجابة البرنامج في زمن التشغيل ... والأن كل ذلك .. كله , مع الأنماط الصارمة والأغراض , والأستدعاءات , وأكواد الكومبايلر المحسنة لن تفيدك أي شيء عندما ترسل الأستعلام كعبارة نصية بين إشارتي اقتباس لإنه لن يتم الحكم عليه والتعامل معه حتى لحظة إرسالة إلى برنامج إدارة قاعدة البيانات ,
ببساطة SQL رائعة جدا , ولكن توجد فجوة كبيرة بينها وبين منطق برنامجك في العمل , إنها منعزلة وخارج السياق ولا يمكنك أن تدمجها مع البرنامج بالطريقة الكافية للإستفادة من مزايا لغة البرمجة التقليدية كقوة الأنماط او المنقح أو غيرها من مئات التقنيات المعتادة والمهمة في عالم البرمجة اليوم ..
وهنا يكمن دور LINQ ..
ردم الفجوة بين منطق البرنامج القائم لديك وبين تقنيات معالجة كميات كبيرة من البيانات (ولنقل sql كمثال) والتزويد بحل محلي مدمج مع لغة البرمجة يتولى عملية التعامل مع التخزين الكبير للمعطيات .
هكذا حل سيكون بالتأكيد متوافق مع نحو (Syntax ) لغة البرمجة , فهو بالنهاية نوع جديد من التعليمات يتعلم علية المبرمج بسهولة بالغة لكي يعفية من الغوص في تفاصيل نحو لغات وتقنيات أخرى , لاتنسى أنك مضطر لتعلم النحو الخاص بsql مثلا عند الرغية بإجراء أي برنامج يحتك مع قواعد بيانات كبيرة الحجم مخزنة على وسيط محلي أو خارجي .
هذا ليس هجوم على تقنيات معالجة البيانات الحالية او هجوم على sql نفسها
Sql واضحة ومعبرة بقوة وتلبي الهدف الذي خلقت من أجلة بشكل أمثلي
ولكن تكمن المشكلة أن sql دائما بعيدة وغريبة عن برنامجك , حيث تشعر وكأن البرنامج أصبح مقسوم إلى جزأين منطقيين : مستوى التطبيق , ومستوى قاعدة البيانات الذي يعبر عنه باستعلامات الsql ... يمكن التقريب بين هذين الجزأين باستخدام بعض التقنيات مثل stored procedures والتي تستطيع نقريب الكود اكثر من البيانات ..ولكن لازال الوضع قاصرا وعليك القيام بالكثير للحصول على نتائج مثالية باستخدام هذا التصور .
عمليا بإمكاننا القول أنه يوجد إنقطاع في دورة حيات التطبيقات الحالية وهذا الإنقطاع في المشروع يمثل فرصة سانحة للإخطاء البشرية كما أنه سضيع سلسلة التنفيذ .
ماذا لو تمكنت من إنجاز تسلسل منطقي محدد على بيانات ضخمة من داخل لغة البرمجة التي تعمل عليها , باستخدام وسائل معتادة كالأغراض , أنماط المعطيات ,المتحولات والتقنيات الأخرى في شفرتك الطبيعية من دون الحاجة لتقوم بعملية الوصل السابقة .
هذا مايهدف إلية LINQ
LINQ سيكون دمج بين نحو لغة برمجة ما syntax , وبين البنية التحتية لمنصة .NET لدعم مقدرات استعلامية مشابه للsql من ضمن لغة البرمجة نفسها , مما يتيح التعامل مع البيانات في مجال لغة البرمجة نفسها وليس في مجال تقنيات الوصول للبيانات .
وهنا الجزء المثير من القصة
LINQ مستقل عن SQL , فاستعلامات LINQ تشغل على بنية معطيات معرفة تستطيع تمثيل النمط IENumerable وهذا يشمل قواعد البيانات وغيرها .
تخيل أنك تستطيع أن تقوم باستعلامات ومشاهد معقدة للبيات المخزنة ضمن برنامجك في اللوائح , المجموعات ,الأنماط التعدادية , وحتى المصفوفات كذلك ..
تريد ان ترتب مصفوفة من الأعداد الصحيحة ؟ إذا قم بانشاء استعلام ضمني بعبارة شبيهه بـ order by .
ستكسب بهذه الطريقه أكثر بكثير من كل ميزات الsql التقليدية , حيث أصبحت تتعامل مع أنواع أكثر من البيانات , وأغلقت الفجوة بين البيانات والكود , واستخدمت نحو قياسي أكثر حسب كل لغة برمجة ... والمزيد
هل سيتم الإستغناء عن sql ..
مستحيل !!
سيتم الإعتماد على sql من قبل LINQ نفسه في كثير من الأحيان .. فالكثير من قواعد البيانات مثلا لديها مزايا استعلامات خاصة بها تعتمد على طريقة تخزينها للبيانات ضمنها وطريقتها بالتعامل مع هذه البيانات ..
الحل كما هو متوقع أن الطرف النهائي سيأخذ استعلام LINQ ويولد منه عبارة sql مناسبة لها ليقوم برنامج إدارة قاعدة البيانات بتولي استجابة لحظية لها .
وبقية الانماط التي يتعامل معها LINQ (المصفوفات مثلا ) طرائق خاصة بكل منها لسنا بصدد ذكرها هنا .
مايجعل الموضوع فعالا وثوريا أنه يمكن تضمين هذه الأنماط وسائل خاصة لاسترجاع المعلومات المشروط بشكل داخلي (سريع وكفوء ومتخصص) حيث يمكن أن يتولى الصنف إرجاع المعلومات التي طلبت منه من الخارج وفق ما يناسبة في الداخل .. ربما يعتبر هذا تفكير مستقبلي ولكني أعتقد أنه سيكون وارد ومدروس أمام مصنعي LINQ ..
هكذا تقنية ستسهل بشكل كبير تصنيع تقنيات حوسبة متفرعة ضمن أدوات برمجية بسيطة يستطيع استخدامها المطورون يوميا بسهولة فائقة وقوة جامحة ..
هل LINQ متكامل
لا أعرف فلم تصدر معلومات كافية عن LINQ بعد .. ولكن عادة هذا النوع من التقنيات التي تزيد من محلية وخصخصة الأدوات المتعلقة باسترجاع البيانات يعمل بنمط Binding أو bounded بهدف القيام بعملية مزامنة آلية بين ما أملكة بين يدي وبين البيانات المخزنة في وسيط بعيد , لإن الأحداث المقدوحة ستنتظر استجابة محددة من النظام ,, وهذا موضوع كرية ومعقد قليلا ولابد ان يسبب عدد من المشاكل
تخيل لو تم طلب استعلام sql من الخارج , مكونات الأخراج تبقى في حالة إنتظار لإنها تعمل في نمط binding مما يجعل حالتها الآنية متعلقة بعودة الاستجابة من قاعدة االبيانت إليها , ربما تطول العملية ويتسبب ذلك باشكالية ما , مثلا جمود الواجهة , أو زيادة كلفة خوارزميات الإضافة والتحديث , أو عدم معالجة كافية لتصرف المستخدم في وقت التنفيذ الخ ..
بعض التقنيات الجديدة كمفهوم ECO الذي طرح مع Delphi2005 Studio استطاع التغلب على ذلك بفاعلية مما جعلة تقنية ثورية وسبب له سيط كبير بين أوساط أخصائيي التقنية , حيث نجح ECO بالتقريب بين أفكار هندسة البرمجيات (مخططات UML مثلا) وبين منطق كتابة البرنامج , مما قرب بين النظرية والتطبيق , وقلل مستوى الخطأ بالتكويد إلى درجة منخفضة , جديد ECO هو أنك تكتب برنامجا تم التفكير فيه بطريقة هندسة البرمجيات , وتستخدم مخططات uml وأفكار تصورية لتمثيل الإستجابة المتعلقة بادخال/استرجاع البيانات من قاعدة بيانات مثلا , أو التعامل مع تطبيق ويب أو غيرها ..
ولكن السؤال هل يمكن ل LINQ أن ينجح بهكذا تحدي رغم الإ‘ختلاف الكبير بين الأثنين وبين ظروف كل منهما .. لنترك ذلك للزمن .
لنرى مثلا كم ستكون كمية الخطر المتوقع بمثال بسيط, تطبيقك متصل مع قاعدة البيانات وحصل تغيير على أسم احد الجداول أو الحقول أو نوع بيانات هذا الحقل ,, الاستجابة المتوقعة هي للأسف .... أنهيار البرنامج ..
على الأقل بالنسبة للمدى المنظور لايبدو ان LINQ وجد حل فعلي لهذه المشكلة بعد .
ماعدا ذلك اظن أن المشكلة الوحيدة ستكون أن Linq على الغالب سيجر تعقيدات إنشاء الاستعلام إلى برنامجك , أي أن ضريبة استخدام أستعلام مضمن لابد من دفعها بالقلق حول تفاصيل إنشاء الاستعلام التي ربما لم تكن مهتم بها قبلاً .
من سيدعم LINQ ؟
على المدى المنظور يتوقع أن تدعمة مبدأيا لغات البرمجة التي تستطيع العمل فوق منصة .NET مثل C# , Delphi.NET وغيرها ..
وإذا أصبح LINQ مفهوم برمجي , أو تقنية قياسيه قد ينجر الحبل لدعم اجيال أخرى من اللغات .
المصدر
