SAX مقابل XmlTextReader - SAX في C#

Question

أحاول قراءة مستند XML كبير وأردت القيام بذلك على شكل أجزاء مقابل مستندات XML كبيرة XmlDocumentطريقة قراءة الملف بأكمله في الذاكرة.أعلم أنه يمكنني استخدامها XmlTextReader للقيام بذلك ولكني أتساءل عما إذا كان أي شخص قد استخدم SAX لـ .NET؟أعلم أن مطوري Java يقسمون بها وكنت أتساءل عما إذا كان الأمر يستحق تجربتها، وإذا كان الأمر كذلك، فما هي فوائد استخدامها.أنا أبحث عن تفاصيل.

Answer 1

إذا كنت تتحدث عن ساكس ل.NET, ، لا يبدو أن المشروع قد تمت صيانته.الإصدار الأخير كان منذ أكثر من عامين.ربما حصلوا عليها بشكل مثالي في الإصدار الأخير، لكنني لن أراهن على ذلك.يبدو أن المؤلف، كارل واكلاويك، قد اختفى من على الشبكة.

أما بالنسبة لـ SAX ضمن Java؟أنت تراهن، إنه أمر رائع.لسوء الحظ، لم يتم تطوير SAX مطلقًا كمعيار قياسي، لذلك قامت جميع المنافذ غير التابعة لـ Java بتكييف واجهة برمجة تطبيقات Java لتلبية احتياجاتها الخاصة.على الرغم من أن DOM عبارة عن واجهة برمجة تطبيقات رديئة جدًا، إلا أنها تتميز بكونها مصممة للغات وبيئات متعددة، لذلك من السهل تنفيذها في Java وC# وJavaScript وC وما إلى ذلك.

Answer 2

إذا كنت تريد فقط إنجاز المهمة بسرعة، فإن XmlTextReader موجود لهذا الغرض (في .NET).

إذا كنت تريد أن تتعلم معيارًا فعليًا (ومتوفر في بعض لغات البرمجة الأخرى) يكون مستقرًا وسيجبرك على البرمجة بكفاءة وأناقة، ولكنه أيضًا مرن للغاية، فابحث في SAX. ومع ذلك، لا تضيع وقتك إلا إذا كنت تريد إنشاء موزعي XML مقصورين على فئة معينة.بدلاً من ذلك، ابحث عن المحللين اللغويين من الجيل التالي (مثل XmlTextReader) للنظام الأساسي الخاص بك.

موارد ساكس
تمت كتابة SAX في الأصل لـ Java، ويمكنك العثور على المشروع الأصلي مفتوح المصدر، والذي ظل مستقرًا لعدة سنوات، هنا:http://sax.sourceforge.net/

يوجد منفذ C# لنفس المشروع هنا (مع مستندات HTML كجزء من التنزيل المصدر)؛كما أنها مستقرة:http://saxdotnet.sourceforge.net/

إذا لم يعجبك تطبيق C#، فيمكنك دائمًا اللجوء إلى الرجوع إلى ملفات COM DLL عبر COMInterop باستخدام MSXML3 أو إصدار أحدث: http://msdn.microsoft.com/en-us/library/ms994343.aspx

المقالات التي تأتي من عالم Java ولكنها ربما توضح المفاهيم التي تحتاجها لتكون ناجحًا مع هذا النهج (قد يكون هناك أيضًا كود مصدر Java قابل للتنزيل والذي يمكن أن يكون مفيدًا وقد يكون من السهل تحويله إلى C#):

• إخراج مستندات XML كبيرة الحجم، الجزء 1 (http://www.ibm.com/developerworks/xml/library/x-tipbigdoc.html)
• إخراج مستندات XML كبيرة الحجم، الجزء 2 (http://www.ibm.com/developerworks/xml/library/x-tipbigdoc2.html)
• استخدم مرشح SAX لمعالجة البيانات (http://www.ibm.com/developerworks/xml/library/x-tipsaxfilter/)

سيكون التنفيذ مرهقًا.لقد استخدمت SAX فقط في أيام ما قبل .NET، ولكنه يتطلب بعض تقنيات البرمجة المتقدمة جدًا. في هذه المرحلة، الأمر لا يستحق العناء.

مفهوم مثير للاهتمام لمحلل هجين
يصف هذا الموضوع محللًا مختلطًا يستخدم .NET XmlTextReader لتنفيذ محلل يوفر مزيجًا من فوائد DOM وSAX...
http://bytes.com/groups/net-xml/178403-xmltextreader-versus-dom

Answer 3

أعتقد أنه لا توجد فوائد لاستخدام SAX على الأقل لسببين:

1. SAX هو نموذج "دفعي" بينما XmlReader هو محلل سحب يحتوي على عدد من الفوائد.
2. الاعتماد على مكتبة تابعة لجهة خارجية بدلاً من استخدام واجهة برمجة تطبيقات .NET القياسية.

Answer 4

أنا شخصياً أفضل نموذج SAX نظرًا لأن XmlReader يحتوي على بعض الفخاخ المزعجة حقًا التي يمكن أن تسبب أخطاء في التعليمات البرمجية الخاصة بك والتي قد تتسبب في تخطي التعليمات البرمجية الخاصة بك للعناصر.سيتم تنظيم معظم التعليمات البرمجية حول نموذج while(rdr.Read())، ولكن إذا كان لديك أي "ReadString" أو "ReadInnerXml()" داخل تلك الحلقة، فستجد نفسك تتخطى العناصر في التكرار التالي.

نظرًا لأن SAX يعتمد على الحدث، فلن يحدث هذا أبدًا لأنه لا يمكنك تنفيذ أي عمليات قد تتسبب في قيام المحلل اللغوي الخاص بك بالبحث للأمام.

شعوري الشخصي هو أن Microsoft قد اخترعت فكرة أن XmlReader أفضل مع شرح نموذج الدفع/السحب، لكنني لا أشتريه حقًا.لذلك تعتقد Microsoft أنك لا تحتاج إلى إنشاء جهاز حالة باستخدام XmlReader، وهذا لا يبدو منطقيًا بالنسبة لي، ولكن على أي حال، هذا مجرد رأيي.