س:
هل صارت تقنية ADO.NET خارج
الخدمة، وحلت محلها التقنيات الأحدث مثل Entity
Framework؟
ج:
لا يمكن القول بهذا، للأسباب الموضحة في النقاط التالية:
1- تقنية ADO.NET هي الأساس الذي بُنيت عليه التقنيات التالية مثل LinQ To SQL و Entity Framework.. وهذا معناه أنك
تستطيع استخدامها لفعل كل ما تفعله التقنيات الأخرى وأكثر.
2- استخدام النموذج التصوري Conceptual Model وإنشاء الكينونات Entities كما في L2SQL و EF يوفر
الكثير من الوقت والجهد عند التعامل مع قواعد بيانات كثيرة الجداول بينها علاقات،
ويتم عرض البيانات من معظم هذه الجداول للمستخدم، أو يقوم هو بإدخال البيانات فيها..
في هذه الحالة تقوم التقنيات الحديثة بإنتاج الكود اللازم لإنشاء تطبيق متعددة
الطبقات n-Tier Applications ومن
ثمّ يكون استخدام استعلامات LinQ أكثر اختصارا وراحة، والكود الذي يكتبه المستخدم أقل ما يمكن.
3- لكن كل هذا لا فائدة منه في أنواع
أخرى من التطبيقات التي تتعامل مع قواعد بيانات ضخمة لا تعرض الكثير من البيانات
المترابطة للمستخدم ولا تستقبل منه مدخلات مباشرة، وإنما يحصل منها المبرمج على
نتائج بحث معينة، يعرض بعضها للمستخدم بطريقة بسيطة.. على سبيل المثال: لو لديك
تطبيق محرك بحث يبحث في قاعدة بيانات ضخمة عن بعض الكلمات، أو برنامج معجم يبحث عن
معاني الكلمات، أو محلل صرفي يبحث عن جذور الكلمات أو ما شابه.. لن يكون النموذج
التصوري مفيدا هنا بل ربما يكون عبئا!
4- بشكل
عام، تقنية ADO.NET هي
ملجأ المبرمجين حينما تكون السرعة والكفاءة مطلبا جوهريا في البرنامج بسبب طبيعة
قاعدة البيانات.. كائن الاتصال Connection Object وكائن الأمر Command Object وقارئ البيانات Data Reader
تقدم تحكما كاملا وسريعا في كيفية الاتصال بقاعدة البيانات والحصول
على البيانات المطلوبة بدقة باستخدام استعلامات SQL.. خاصة أن استعلام LinQ يعجز أحيانا عن إنتاج بعض استعلامات سيكويل، وفي بعض الأحيان ينتج
استعلامات أقل كفاءة مما يمكن أن تكتبه أنت مباشرة.
5- بينما النموذج التصوري هو الملاذ
المريح للمبرمج الذي ينشئ واجهة استخدام معقدة فيها استعلامات كثيرة متشابهة،
وفيها إدخال بيانات وتحديث وحذف وما شابه.. في هذه الحالة توفر التقنيات الحديثة
مثل EF وقتا هائلا في إنشاء
الكينونات وتختصر استعلامات LinQ الكثير من الكود والوقت والجهد.
6- هناك سبب عملي آخر يجبر المبرمج على
تعلم تقنية ADO.NET.. أن
معظم التطبيقات الموجودة في الشركات اليوم مكتوبة بهذه التقنية، وقد يطلب منك
تصحيح خطأ فيها، أو إضافة تطوير إليها.. لا تتوقع أن أحدا سيهجر تطبيقا أنفق عليه
مالا ويعمل معه بشكل مستقر وكفء، لمجرد أنك تستخدم طريقة أسهل في كتابة الكود!..
سيحتاجون هذه الطريقة الأسهل لتوفير وقت كتابة التطبيقات الجديدة، لكن تغيير كود
التطبيقات القديمة أمر خارج أي حسابات اقتصادية!
باختصار:
استخدم التقنية التي تحقق احتياج برنامجك.. ولا مانع أن تمزجهما معا في بعض
الحالات التي لا يمكن أن تستغني فيها عن مزايا كل منهما.
ليست هناك تعليقات:
إرسال تعليق
ملحوظة: يمكن لأعضاء المدونة فقط إرسال تعليق.