RAD Studio 13.0 "Ganymede" BETA
#1
الان النسخة 13 هي في طور التجريب ، ترسل فقط للمطورين المنتسبين لها للتجريب و الاعلان عن الاخطاء

RAD Studio 13.0 "Ganymede" BETA

https://blogs.embarcadero.com/update-sub...mede-beta/
‏اللّهمّ فرّج أُموراً ضَاقت بها صُدورنا وعجزت بها حيلتنا وقلّ بها صَبرنا الّلهمّ أَسعِد قلوبنا بما أنتَ أعْلَمُ بِهِ مِنّا
[-] كل من 2 users say قال شكرا ل larbiparadox على المشاركة المفيدة
  • الفجر الابيض, أبو معاذ
الرد
#2
(29-06-2025, 07:55 AM)larbiparadox كتب : الان النسخة 13 هي في طور التجريب ، ترسل فقط للمطورين المنتسبين لها للتجريب و الاعلان عن الاخطاء

RAD Studio 13.0 "Ganymede" BETA

https://blogs.embarcadero.com/update-sub...mede-beta/

لمعرفة المميزات الجديدة والتصليحات التي تمت في هذه النسخة، يمكن الاطلاع على الملف في الرابط التالي.

Overview of RAD Studio Ganymede Beta
[-] كل من 3 users say قال شكرا ل mo7ammed على المشاركة المفيدة
  • أبو معاذ, larbiparadox, annabil23
الرد
#3
تم تحديث نسخة البيتا من دلفي 13، يمكن الاطلاع على المميزات الجديدة والتصليحات هنا:
Ganymede 3084
[-] كل من 3 users say قال شكرا ل mo7ammed على المشاركة المفيدة
  • أبو معاذ, lkhalid, annabil23
الرد
#4
عاملين ضجة في الفيسبوك وتيرناي وماادراك ما تبرناي وتحديث ونسخة جديدة كلها على

كود :
ShowMessage (if Left < 100 then 'Small' else 'Large' + 'Nice')

تركوا التطوير والتحديث لكثير من المكونات و الاخطاء ودعم اللغات و كم شهر او كم سنة ليطلعوا علينا بي  Left < 100 then 'Small'
إذا رأيت منتجاً مجانياً فأعلم بأنك أنت السّلعة
[-] كل من 1 user says قال شكرا ل الفجر الابيض على المشاركة المفيدة
  • أبو معاذ
الرد
#5
(16-08-2025, 08:46 PM)الفجر الابيض كتب : عاملين ضجة في الفيسبوك وتيرناي وماادراك ما تبرناي وتحديث ونسخة جديدة كلها على

كود :
ShowMessage (if Left < 100 then 'Small' else 'Large' + 'Nice')

تركوا التطوير والتحديث لكثير من المكونات و الاخطاء ودعم اللغات و كم شهر او كم سنة ليطلعوا علينا بي  Left < 100 then 'Small'

Big Grin Big Grin Big Grin

كما قال أخونا إبراهيم الليبي ،
خرخز بالعود و أعطيها للمسعود  Big Grin
اللهم اجعلني من أهل القرآن ، الذين هم أهلك و خاصتك.
تذكر بأن الوقت الذي تلهو فيه ، غيرك يبني مجده فيه.
[-] كل من 1 user says قال شكرا ل أبو معاذ على المشاركة المفيدة
  • الفجر الابيض
الرد
#6
أي والله صدق delphi4us حينما قال (خربش بالعود واعطي لمسعود)
بيئة رائعة وسريعة ولكن سيضيعونها وسيهجرهم الكثير من المبرمجين فانا عن نفسي بدأت او عدت الى الدوت نت من جديد وحاولت مع فايرمونكي كثيرا لتطويعه ولكنه اضاعة للوقت بدل من ان تنجز عملك تبقى تصلح مشاكلهم وعلى الاقل Maui تتطور بسرعة ولها مجتمع كبير وادوات كثيرة وكل شئ مجاني و NetCore اصبح غير مغلق ويمكنه العمل باي مكان
وعلى العموم الدوت نت مع Native AOT لها مستقبل كبير ومايكروسوفت لا تضع يدها في شئ وتهمله كما تفعل امبركاديرو وتطورها سريع وتحديثها دائما كبير
سيبقى دلفي مجرد اطلال نمر بها ونزورها فقط لنتذكر الماضي والحلم الجميل الذي كنا نحلمه معا
إذا رأيت منتجاً مجانياً فأعلم بأنك أنت السّلعة
[-] كل من 1 user says قال شكرا ل الفجر الابيض على المشاركة المفيدة
  • أبو معاذ
الرد
#7
(17-08-2025, 01:04 PM)الفجر الابيض كتب : أي والله صدق delphi4us حينما قال (خربش بالعود واعطي لمسعود)
بيئة رائعة وسريعة ولكن سيضيعونها وسيهجرهم الكثير من المبرمجين فانا عن نفسي بدأت او عدت الى الدوت نت من جديد وحاولت مع فايرمونكي كثيرا لتطويعه ولكنه اضاعة للوقت بدل من ان تنجز عملك تبقى تصلح مشاكلهم وعلى الاقل Maui تتطور بسرعة ولها مجتمع كبير وادوات كثيرة وكل شئ مجاني و NetCore اصبح غير مغلق ويمكنه العمل باي مكان
وعلى العموم الدوت نت مع Native AOT لها مستقبل كبير ومايكروسوفت لا تضع يدها في شئ وتهمله كما تفعل امبركاديرو وتطورها سريع وتحديثها دائما كبير
سيبقى دلفي مجرد اطلال نمر بها ونزورها فقط لنتذكر الماضي والحلم الجميل الذي كنا نحلمه معا

كلامك غلط في غلط (ليس دفاعا عن اللغة أو تحيز)
--
من يظن أن Delphi انتهى أو أن النسخة الجديدة جاءت فقط بسبب ternary operator فهو لا يعرف فلسفة هذه الأداة أصلاً. Delphi 13 مثله مثل كل الإصدارات السابقة: البداية وليست النهاية، لأن كل إصدار رئيسي يتبعه تحديثات فرعية (13.1، 13.2…) وهذا النمط ثابت منذ سنين.
وخليني أقولها بصراحة: من يشكي أن بيئة التطوير ناقصة مقارنة بمنافسيها فهو ليس بمبرمج محترف، لأن النقص في المكتبات ليس عيب الأداة بل عيب فيك إذا لم تستطع توليد ما تحتاجه بنفسك. Delphi تعطيك الأساسيات الصلبة، أي نفس المواد الخام التي يحتاجها المهندس لبناء ما يشاء. وهنا يكمن جمالها: البساطة والوضوح، بدون “عكازات” تزيدك كسلاً.
الفرق بين Delphi وغيره هو كالفرق بين مصنع سيارات و ورشة تركيب LEGO. المصنع (Delphi) يعطيك الأدوات الهندسية الحقيقية، بينما LEGO (بعض الأطر الأخرى) تعطيك قطع بلاستيكية جاهزة، كل ما عليك هو تركيبها… فتظن نفسك “مبرمجاً”.
Delphi ليس Python ولا Scratch… هو بيئة للمهندسين المبرمجين الذين يستمتعون بالتصميم من الأساسيات ويشعرون فعلًا أنهم ينتجون برمجيات حقيقية، لا مجرد لواصق وألعاب تعليمية.

واللي يقارن بجدية مع Microsoft، لازم يتذكر: مايكروسوفت نفسها عندها سجل طويل من قتل تقنيات فجأة وترك مجتمع كامل من المطورين في العراء. من أمثلتها:
  • مايكروسوفت أثبتت مراراً وتكراراً أن استراتيجيتها في تطوير واجهات المستخدم (GUI) عبارة عن دوامة لا تنتهي:
    • بدأت مع WinForms (2002)، إلى اليوم لا يزال هناك ملايين التطبيقات عليه، لكن مايكروسوفت نفسها تقول إنه "تقنية قديمة".
    • بعدها جاءت WPF (2006) وأُعلن أنها المستقبل الحقيقي للـ GUI… إلى أن تم تهميشها لصالح UWP.
    • ثم Silverlight (2007) كمنصة "الويب الغني"، وتم إعدامه رسمياً 2012.
    • Windows Phone و UWP (2010–2015): مطورون استثمروا سنوات، ثم فجأة تم الإعلان عن موت النظام.
    • Xamarin.Forms (2014): اشترتها مايكروسوفت وروّجت لها، ثم تحولت إلى MAUI.
    • WinUI3 (2020) supposed to be the “native way forward” → لم يكتمل إلى اليوم.
    • والآن MAUI، الذي لم يزل في مرحلة غير مستقرة، وحتّى أدوات التصميم GUI غير موجودة: المطور يكتب XAML يدوياً مثل ما كنا نكتب HTML سنة 1998!

  • ? Joel Spolsky كتب سنة 2002 في مقاله الشهير "Fire and Motion" أن مايكروسوفت لديها استراتيجية:
    إقتباس :أن تُغرق السوق بالتقنيات الجديدة واحدة تلو الأخرى، فلا يملك المطور وقتاً ليلحق بها، بينما الشركة نفسها تستمر في الحركة وتُسقط التقنيات السابقة بلا رحمة.
    وهذا بالضبط ما حصل ويستمر حتى اليوم في مجال الـ GUI.
إذن، قبل ما نتكلم عن “مساوئ تطور Delphi”، لازم نسأل: هل تفضل أداة مستقرة ومرنة مستمرة من التسعينات، أم تركض وراء عملاق يغير رأيه كل 5 سنوات؟

? المقارنة مع Delphi هنا قاتلة:
  • Delphi بدأ مع VCL (1995) → مازال حيّ ويعمل بلا مشاكل مع Windows 11.
  • FMX (FireMonkey) قديم نسبياً لكنه مستمر ويتطور.
  • نفس الكود الي كتبته قبل 15–20 سنة مازال يشتغل بدون مشاكل.
الخلاصة:
إذا أردت بيئة مستقرة لا تجعلك تعيد كتابة كودك كل 5 سنوات → Delphi خيار أكثر أماناً من اللحاق بأمواج مايكروسوفت المتقلبة.

? المعامل الشرطي الحقيقي يجب أن يدعم التقييم القصير (Short-Circuit Evaluation)
في دلفي، دالة
كود :
IfThen
ليست بمعامل شرطي حقيقي، لأنها تقوم بتقييم الفرعين (True/False) معًا قبل استدعاء الدالة. لهذا السبب، الكود مثل:

كود :
Writeln(IfThen(Assigned(LSomething), LSomething.MyField, 'Not Assigned'));

يؤدي إلى خطأ وصول للذاكرة (Access Violation) حتى وإن كانت نتيجة Assigned(LSomething) = False.

بينما في اللغات الأخرى مثل C/C#، المعامل الثلاثي condition ? expr1 : expr2 يقوم بتنفيذ الفرع المختار فقط، مما يضمن الأمان والاختصار.

الخلاصة: آن الأوان أن يدعم دلفي معامل شرطي حقيقي بالتقييم القصير، لا مجرد شكل نحوي.
[-] كل من 4 users say قال شكرا ل brave على المشاركة المفيدة
  • larbiparadox, أبو معاذ, firebird78, ELARAPY
الرد
#8
ربما لم تجرب ان تكون قد تكفلت واستملت ثلاث منظومات او اربعة بوقت واحد وتعمل عليهم في وقت واحد

وقتها تعلم ان المتعة التي تقولها لتطويع ما ينقص لم تعد موجودة ولا وقت لها وكل ما يهم اكمال العمل باسرع ما يمكن

بالنسبة لتطبيقات سطح المكتب مع انني راض عنها ولكن كان يمكن ان يكون فيها تطوير فمنذ ان استخدمت الدلفي في عام 2013 تقريبا لم يتغير شئ

حتى الان 2025 لم يتم زيادة حدث واحد ولم يتم دق مسمار فيها

نحن نتحدث عن حوالي تجربة 14 سنة ما الذي طورته امبركاديرو مقارنة بتطور منافسيها

لا شئ يذكر او مهم عدا ثقنيات وادوات تطورها شركات هنا وهناك واشخاص من هنا وهناك

اما مايكروسوفت انا عن نفسي في عام 2003 تركت كل شئ لها بالبرمجة اما الان بعد ان تطورت عدت اعمل بانتاجها

من الطبيعي أن تتغير تقنيات واجهات المستخدم، لأننا لا نعيش في بيئة ثابتة. مايكروسوفت لم تكن في "دوامة"، بل في رحلة تطور استجابت فيها لتغيرات السوق، الأجهزة، وسلوك المستخدمين.

WinForms كانت ثورة في وقتها، ولا تزال تعمل بكفاءة في ملايين الأنظمة، وهذا ليس عيبًا بل دليل على الاستقرار الخلفي.

WPF لم تهمش، بل لا تزال مدعومة رسميًا، وتستخدم في تطبيقات ضخمة مثل Visual Studio نفسه.

Silverlight انتهى لأنه كان يعتمد على متصفح وإضافات، تمامًا كما انتهى Flash وJava Applets. هذا ليس فشلًا، بل نهاية طبيعية لتقنية تجاوزها الزمن.

UWP وWindows Phone كانت محاولة لتوحيد التجربة عبر الأجهزة، لكنها اصطدمت بواقع السوق. ومع ذلك، كثير من أفكارها انتقلت إلى WinUI وMAUI.

Xamarin.Forms لم تقتل، بل تطورت إلى MAUI، الذي يجمع بين قوة .NET ومرونة التطوير عبر المنصات.

أما القول إن المطور يكتب XAML يدويًا، فهو مثل القول إن المطور يكتب HTML يدويًا: نعم، لأننا نريد تحكمًا رمزيًا دقيقًا، لا واجهات سحب وإفلات سطحية.

التقنية ليست طقوسًا جامدة، بل أدوات تتغير لتخدم الواقع. من يظن أن الثبات هو ميزة، فليتأمل كيف انتهت Delphi نفسها إلى هامش السوق، لأنها لم تواكب التحولات الكبرى في الويب، المحمول، والسحابة.

.NET اليوم ليس مجرد منصة، بل نظام بيئي متكامل: من الواجهة إلى السحابة، من الذكاء الاصطناعي إلى قواعد البيانات، من MAUI إلى Blazor، من C# إلى F#، من GitHub Copilot إلى Azure DevOps.

لا أحد ينكر أن Delphi كانت في وقتها أداة قوية، لكن الزمن تغير، والمشاريع الحديثة تحتاج أدوات تواكب الواقع التقني، لا تكتفي بالحنين.

FireMonkey، رغم كونه محاولة لتقديم واجهات متعددة المنصات، إلا أنه يعاني من:

ضعف في الأداء الرسومي مقارنة بـ MAUI أو WPF.

افتقار إلى دعم حقيقي للأنظمة الحديثة مثل Android 14 أو iOS 17.

غياب أدوات تصميم GUI متقدمة، مما يجعل تجربة التطوير مرهقة.

مكونات VCL، رغم استقرارها، إلا أنها:

لا تزال تعتمد على مفاهيم تعود إلى التسعينات.

تفتقر إلى أحداث حديثة مثل Async Await أو PropertyChanged الديناميكي.

لا تتكامل بسهولة مع REST APIs أو تقنيات الويب الحديثة.

بيئة Delphi نفسها:

لا تملك نظام إدارة حزم قوي مثل NuGet.

لا تملك مجتمعًا نشطًا مثل .NET أو GitHub.

لا تواكب التطورات في الذكاء الاصطناعي، السحابة، أو التطوير عبر المنصات.

من يريد أن يبني المستقبل، لا يشتكي من التغيير… بل يتقنه.
إذا رأيت منتجاً مجانياً فأعلم بأنك أنت السّلعة
الرد
#9
(21-08-2025, 12:11 PM)الفجر الابيض كتب : ربما لم تجرب ان تكون قد تكفلت واستملت ثلاث منظومات او اربعة بوقت واحد وتعمل عليهم في وقت واحد

وقتها تعلم ان المتعة التي تقولها لتطويع ما ينقص لم تعد موجودة ولا وقت لها وكل ما يهم اكمال العمل باسرع ما يمكن

بالنسبة لتطبيقات سطح المكتب مع انني راض عنها ولكن كان يمكن ان يكون فيها تطوير فمنذ ان استخدمت الدلفي في عام 2013 تقريبا لم يتغير شئ

حتى الان 2025 لم يتم زيادة حدث واحد ولم يتم دق مسمار فيها

نحن نتحدث عن حوالي تجربة 14 سنة ما الذي طورته امبركاديرو مقارنة بتطور منافسيها

لا شئ يذكر او مهم عدا ثقنيات وادوات تطورها شركات هنا وهناك واشخاص من هنا وهناك

اما مايكروسوفت انا عن نفسي في عام 2003 تركت كل شئ لها بالبرمجة اما الان بعد ان تطورت عدت اعمل بانتاجها

من الطبيعي أن تتغير تقنيات واجهات المستخدم، لأننا لا نعيش في بيئة ثابتة. مايكروسوفت لم تكن في "دوامة"، بل في رحلة تطور استجابت فيها لتغيرات السوق، الأجهزة، وسلوك المستخدمين.

WinForms كانت ثورة في وقتها، ولا تزال تعمل بكفاءة في ملايين الأنظمة، وهذا ليس عيبًا بل دليل على الاستقرار الخلفي.

WPF لم تهمش، بل لا تزال مدعومة رسميًا، وتستخدم في تطبيقات ضخمة مثل Visual Studio نفسه.

Silverlight انتهى لأنه كان يعتمد على متصفح وإضافات، تمامًا كما انتهى Flash وJava Applets. هذا ليس فشلًا، بل نهاية طبيعية لتقنية تجاوزها الزمن.

UWP وWindows Phone كانت محاولة لتوحيد التجربة عبر الأجهزة، لكنها اصطدمت بواقع السوق. ومع ذلك، كثير من أفكارها انتقلت إلى WinUI وMAUI.

Xamarin.Forms لم تقتل، بل تطورت إلى MAUI، الذي يجمع بين قوة .NET ومرونة التطوير عبر المنصات.

أما القول إن المطور يكتب XAML يدويًا، فهو مثل القول إن المطور يكتب HTML يدويًا: نعم، لأننا نريد تحكمًا رمزيًا دقيقًا، لا واجهات سحب وإفلات سطحية.

التقنية ليست طقوسًا جامدة، بل أدوات تتغير لتخدم الواقع. من يظن أن الثبات هو ميزة، فليتأمل كيف انتهت Delphi نفسها إلى هامش السوق، لأنها لم تواكب التحولات الكبرى في الويب، المحمول، والسحابة.

.NET اليوم ليس مجرد منصة، بل نظام بيئي متكامل: من الواجهة إلى السحابة، من الذكاء الاصطناعي إلى قواعد البيانات، من MAUI إلى Blazor، من C# إلى F#، من GitHub Copilot إلى Azure DevOps.

لا أحد ينكر أن Delphi كانت في وقتها أداة قوية، لكن الزمن تغير، والمشاريع الحديثة تحتاج أدوات تواكب الواقع التقني، لا تكتفي بالحنين.

FireMonkey، رغم كونه محاولة لتقديم واجهات متعددة المنصات، إلا أنه يعاني من:

ضعف في الأداء الرسومي مقارنة بـ MAUI أو WPF.

افتقار إلى دعم حقيقي للأنظمة الحديثة مثل Android 14 أو iOS 17.

غياب أدوات تصميم GUI متقدمة، مما يجعل تجربة التطوير مرهقة.

مكونات VCL، رغم استقرارها، إلا أنها:

لا تزال تعتمد على مفاهيم تعود إلى التسعينات.

تفتقر إلى أحداث حديثة مثل Async Await أو PropertyChanged الديناميكي.

لا تتكامل بسهولة مع REST APIs أو تقنيات الويب الحديثة.

بيئة Delphi نفسها:

لا تملك نظام إدارة حزم قوي مثل NuGet.

لا تملك مجتمعًا نشطًا مثل .NET أو GitHub.

لا تواكب التطورات في الذكاء الاصطناعي، السحابة، أو التطوير عبر المنصات.

من يريد أن يبني المستقبل، لا يشتكي من التغيير… بل يتقنه.
السلام عليكم،

دعني ادخل في المناقشة قليلاً، انا مبرمج دلفي ودوت نت منذ اكثر من عشرين عام، ولدي خبرة الاثنين بشكل كبير جداً.

لكن رغم حبي للغة سي# ، لكن في النسخ الاخيرة تم اضافة اضافات لها ليجعلو منها قريبة من الجافا سكريبت وال dynamic lanauges مما اضعو كثيرا من المتعة في البرمجة من اجل اختصار عدة اسطر.

ايضاً بخصوص تطوير برامج سطح المكتب مع دوت نت، هل جربت انت تنشيء مشروع به اكثر من 20 فورم وكل فروم يحتوي على عدد كبير من ال controls؟ سوف يصبح المشروع ميت حيث لو كانت جاهزك مواصفاته ممتازة، وسرعة الرسم على الشاشة لا تقارن بدلفي بتاتاً في runtime.

بخصوص هذه النقطة:
إقتباس :لا تتكامل بسهولة مع REST APIs أو تقنيات الويب الحديثة.

بالعكس، يمكن بسهولة الربط وتطوير ال API مع دلفي، انا استخدم Delphi MVC بشكل كبير، وهو رائع وقوي وسريع جداً، ويمكنك ربطه مع اي لغة برمجة.

انا من محبي asp.net وانشأت بها عدة مشاريع، لكن لو جربت Unigui مع دلفي، سوف تدرك ان التطوير به اسرع بكثير واسهل.

استخدم دلفي لو كنت انت تبني المشاريع بنفسك او من ضمن فريق صغير، ففيها سرعة الانجاز اعلى بكثير.

لكن تعلم الدوت نت للحصول على وظائف في الشركات الاكبر، قد يحتاج العمل الى 3 او 4 اضعاف الفريق والوقت، لكن في هذه الشركات لا يهم، المهم ان يكون الفريق كله يعمل ويسهل ايجاد حد اخر يعمل على نفس التقنية.

تحياتي

نقطة اخرى، قوة دلفي تنبع من الشركات التي تبني مكونات لها مثل Dev express, TMS ,وغيرهم، فلديهم مكونات تتكامل مع دلفي وتعطيك حلول قوية، وهناك الكثير من المشاريع المفتوحة المصدر ايضاً تنضم لهم.

جرب التعامل مع قواعد البيانات مع UniDac او Ado.Net، وشوف الفرق، وايضاُ الado.net تعتبر تقنية قديمة ولا تنصح بها ميكرسووف وعليك التعامل مع EntityFramework، وهنا تخسر الكثير من الاداء في التعامل مع قواعد البيانات بسبب الطبقات التي سوف تكون بينك وبين قاعدة البيانات
الرد
#10
إقتباس :ايضاً بخصوص تطوير برامج سطح المكتب مع دوت نت، هل جربت انت تنشيء مشروع به اكثر من 20 فورم وكل فروم يحتوي على عدد كبير من ال controls؟ سوف يصبح المشروع ميت حيث لو كانت جاهزك مواصفاته ممتازة، وسرعة الرسم على الشاشة لا تقارن بدلفي بتاتاً في runtime.

اخشى ما اخشاه ان تكون العشرين سنة التي تعلمتها مجرد فهم لما يطرح بالمنتديات فلا علاقة لما ذكرت  ففيه الكثير من التهويل وقليل من الدقة الهندسية
ليس بالضرورة عدد النماذج (Forms) لا يؤثر على الأداء طالما أنها ليست كلها محملة في الذاكرة في نفس الوقت
عدد العناصر (Controls) داخل النموذج قد يؤثر على زمن التحميل الأولي للنموذج لكنه لا يجعل المشروع ميتاً كما تقول وحتى دلفي نشاهد بطئ نسبي بين نموذج خفيف ونموذج ممتلئ .

.NET (سواء WinForms أو WPF أو MAUI) يستخدم تقنيات ذكية في إدارة الذاكرة والرسم مثل lazy rendering وdouble buffering 

مقارنة واقعية مع Delphi :
الدلفي
سرعة التحميل الأولي
أسرع في بعض الحالات بسبب الرسم المباشر
الدوت نت
أبطأ نسبيًا بسبب abstraction

إدارة الذاكرة
الدلفي
أقل ذكاءً في إدارة الموارد
الدوت نت
Garbage Collection ذكي

دعم الأجهزة الحديثة
الدلفي
محدود في FireMonkey

الدوت نت
واسع في MAUI وWPF

التوسع المستقبلي
الدلفي
صعب بدون إعادة بناء

الدوت نت
سهل عبر MVVM وDI

Delphi قد يكون أسرع في رسم واجهة بسيطة، لكن .NET يتفوق في الاستقرار، التوسع، والتكامل مع النظام البيئي الحديث.

القول بأن المشروع "يموت" بسبب كثرة النماذج أو العناصر غير دقيق هندسيًا. ما يقتل المشروع هو سوء التصميم، لا عدد النوافذ. في .NET، يمكن تحميل النماذج عند الطلب، استخدام UserControls لتقسيم الواجهة، وتطبيق أنماط مثل MVVM لتقليل الحمل على الذاكرة.

أما من ناحية الأداء، فـ .NET يقدم أدوات مثل SuspendLayout, DoubleBuffered, وVirtualization في WPF، وكلها مصممة لتحسين الأداء حتى في الواجهات الثقيلة.

Delphi قد يرسم أسرع، لكنه لا يدير الموارد بذكاء، ولا يتكامل مع REST APIs أو Azure أو الذكاء الاصطناعي كما تفعل .NET.

التقنية ليست سباقًا في "من يرسم أسرع"، بل في "من يبني نظامًا قابلًا للتوسع، الصيانة، والتكامل مع المستقبل".

ADO.NET ليست تقنية مهجورة، بل هي الأساس المنخفض المستوى الذي تبني عليه معظم مكتبات الوصول إلى البيانات في .NET، بما فيها Entity Framework وDapper.

مايكروسوفت لا "تحذر" من استخدامها، بل توصي بها في الحالات التي تتطلب أداءً عاليا وتحكما مباشرا، مثل التطبيقات المالية أو أنظمة الـ OLTP الثقيلة.

من الخطأ اعتبار ADO.NET "تقنية قديمة" فقط لأنها لا تحتوي على ORM. هي أداة منخفضة المستوى، وليست بدائية.

EF (خصوصًا Core) يقدم أداء جيدًا إذا استُخدم بشكل صحيح:

عبر AsNoTracking

واستخدام Compiled Queries

وتجنب Lazy Loading في السيناريوهات الحساسة.

نعم، هناك طبقات إضافية، لكنها تمنحك قابلية صيانة، واختبار، وتجريد لا تحصل عليها مع ADO.NET أو UniDAC.

من يشتكي من أداء EF غالبًا يستخدمه بطريقة غير مثالية، أو يقارن بين سيناريوهات غير متكافئة.

القول بأن ADO.NET قديمة وغير منصوح بها فيه تبسيط مخل. هي أداة قوية لمن يريد التحكم الكامل في الاتصال والاستعلامات، وتُستخدم في الأنظمة الحرجة حتى اليوم. أما Entity Framework، فهو خيار ممتاز لمن يبحث عن إنتاجية وسهولة في التطوير، بشرط أن يفهم حدوده ويستخدمه بذكاء.
أما الأداء، فهو ليس ضحية الطبقات، بل ضحية سوء الاستخدام. من يعرف كيف يوازن بين التجريد والتحكم، سيبني نظاما سريعا وقابلا للصيانة، سواء استخدم EF أو ADO.NET أو حتى Dapper.

لاتقارن بين دلفي والفيجوال ستوديو فبيئة لا يوجد فيها حدث زر عجلة الفأرة لانها لازالت بنفس اسطر البرمجة المكتوبة قبل ظهور عجلة الفأرة من الظلم مقارنتها بنظام حديث وايضا الدوت نت في طريقة للسرعة فهي اسرع الان من اول ما عرفتها في 2003
إذا رأيت منتجاً مجانياً فأعلم بأنك أنت السّلعة
الرد


التنقل السريع :


يقوم بقرائة الموضوع: بالاضافة الى ( 1 ) ضيف كريم