سافترض في هذا الموضوع ان القارئ يعلم ماهو CSOM و ماهو REST.
وكما هو معلوم فان مبرمج الشيربوينت بامكانه الاتصال عن بعد بمنصة الشيربوينت عن طريق نموذجين الذين ذكرتهما .
لكن يوجد سؤال محير دائما ما يخطر ببال المبرمج اي اسلوب استخدم CSOM او REST ؟
لذلك أمل ان يكون هذا الموضوع مساعدا لك على الاختيار حيث ساضع فيه جمله من الامور او معايير المقارنة التي تسهل عليك ذلك . لكن المقارنة المذكورة ليست مقارنة من هو الافضل ؟ : لان الافضل منهما في حالات قد لا يكون الافضل في حالات الاخرى لذلك فان المقارنة بينهما نسبية و ليست مطلقة.
اود ان اذكر 5 امور او اعتبارات مهمة - حسب رأيي - في اختيار الواجهة البرمجية (API) المناسبة لك عند تعاملك مع الشيربوينت :
1- الاعتبارات الفنية :
* من حيث الخدمة المستهدف التعامل معها :
3- قابلية الاختبار :
هذا الامر مهم جدا حيث نعرف كلنا صعوبة اختبار اكواد CSOM .
اعتقد ان هذا المعيار بالذات يصب في صالح REST. حيث انه اسهل في الاختبار لانك عندما تختبر اكواد REST فانك تختبر الويب المتعارف عليه (طلبات HTTP ...) على عكس CSOM فانك تحتاج التعامل مع شيئيات شيربوينت "SharePoint Objects".
عموما انت تحتاج الى ما يسمى ادوات المحاكات mock tools مثل :
- microsoft fakes
- type mock isolator
- nmock
- just mock
4- حماية الملكية الفكرية :
هذا الامر يهم بالاساس من يقوم بنشر التطبيقات على متجر الاوفيس و شيربوينت.
لا يوجد في الحقيقة الية لحماية اكوادك اذا كانت تعمل على المتصفح حيث ان اي احد بامكانه نسخها بسهولة كما انك عندما تستخدم REST سيصبح من السهل معرفة خدمة الويب التي تقوم باستهلاكها و كذلك جميع مدخلات و مخرجات HTTP التي تصدر عن تطبيقك ...
لكن اذا كنت مجبرا على استخدام SharePoint Hosted App و بالتالي على JavaScript اليك بعض الممارسات التي تجعل من عدم احترام الغير لملكية الفكرية امرا صعبا عليهم :
- بامكانك تعقيد الاكواد باستخدام TypeScript مثلا بدلا من كتابة الاكواد مباشرة عن طريق JaveScript
- استخدم JaveScript Obfuscator
5- اعتبارات المبرمج :
هذا اخر اعتبار من حيث ترتيب الاهمية ليس لاني لا احب المبرمجين , على العكس فانا بالاساس مبرمج :) لكن لانه حسب رايي الشخصي لابد للمبرمج ان يتاقلم مع اي لغة يطلب منه التعامل معها.
- نحن نعلم ان CSOM هو اسلوب من انتاج مايكرسفت لذلك اذا حاولت استخدام اسلوب اخر , لا اقول انك لا تستطيع تنفيذ ما تحتاج لكن ستحتاج غالبا الى عمل اضافي.
- حاليا لا يمكنك ان تتعامل مع اجراءات العمل في شيربوينت 2013 (workflows) و خدمة Managed Metadata الا من خلال CSOM لان نقاط REST التي يوفرها شيربوينت حاليا لا يمكنها الاتصال بهذين المكونين .
- اضف الى ما سبق ان قلة الموارد التعليمية الخاصة بـ REST قد تجعل الكثير لا يفضله.
- عدم الرغبة في تعلم REST مع اني اعتقد ان المبرمج لابد ان يكون لديه الرغبة في تعمل الجديد دائما.
الخاتمة:
من يقول ان مستقبل البرمجيات على شيربوينت و غيره في REST مخطأ , قد يكون ذلك صحيحا خارج شيربوينت لكن مع شيربوينت يوجد استثمار كبير جدا من مايكرسفت في CSOM ... و لا اظنهم ستغنون عنه بسهوله !!
وكما هو معلوم فان مبرمج الشيربوينت بامكانه الاتصال عن بعد بمنصة الشيربوينت عن طريق نموذجين الذين ذكرتهما .
لكن يوجد سؤال محير دائما ما يخطر ببال المبرمج اي اسلوب استخدم CSOM او REST ؟
لذلك أمل ان يكون هذا الموضوع مساعدا لك على الاختيار حيث ساضع فيه جمله من الامور او معايير المقارنة التي تسهل عليك ذلك . لكن المقارنة المذكورة ليست مقارنة من هو الافضل ؟ : لان الافضل منهما في حالات قد لا يكون الافضل في حالات الاخرى لذلك فان المقارنة بينهما نسبية و ليست مطلقة.
اود ان اذكر 5 امور او اعتبارات مهمة - حسب رأيي - في اختيار الواجهة البرمجية (API) المناسبة لك عند تعاملك مع الشيربوينت :
1- الاعتبارات الفنية :
* من حيث الخدمة المستهدف التعامل معها :
.NET
|
JavaScript
| |||
CSOM
|
REST
|
CSOM
|
REST
| |
Workflow
|
نعم
|
لا
|
نعم
|
لا
|
Managed Metadata
|
نعم
|
لا
|
نعم
|
لا
|
* من حيث البنية التحتية المستخدمة :
.NET
|
JavaScript
| |||
CSOM
|
REST
|
CSOM
|
REST
| |
Windows / Microsoft
|
نعم
|
نعم
|
نعم
|
نعم
|
LAMP, Android, IOS, …
|
خاص بمايكروسف فقط
|
نعم
|
خاص بمايكروسف فقط
|
نعم
|
* من حيث نوعية تعاملك مع الشيربوينت في عملك :
* حسب طريقة الرفع او نوع الحل البرمجي المراد انتاجه :
2- لاعتبارات الاداء :
البعض لا يهتم بالاداء او Performance الا اذا فقده :)
فعادة لا يتم الالتفات الى مسالة اداء الاكواد الا بعدما يتم اكتشاف ضعف فيه. و في هذا الاطار اؤكد لك ان الاختبارات اثبتت ان استخدام REST عادة ما يتسبب في ارسال طلبات لخادم الشيربوينت اضعاف مضاعفة مقارنة باستخدام CSOM.
سبب ذلك انك عندما تستخدم REST فانك تضطر للاتصال بالخادم في كل عملية : اذا اردت انشاء قائمة تتصل بالخادم , اذا اردت اضافة عنصر واحد الى تلك القائمة ستتصل بالخادم مرة اخرى و هكذا ...
لكن عن طريق CSOM فان ذلك يتم دفعة واحدة على هيئة BATCH. بطبيعة الحال مثل هذا السلوك من REST يؤثر حتى على موارد الشبكة من حيث الحمل الزائد عليها ...
.NET
|
JavaScript
| |||
CSOM
|
REST
|
CSOM
|
REST
| |
فقط للتعامل مع البيانات التي في الشيربوينت
|
*
|
نعم
|
*
|
نعم
|
التعامل مع امكانيات شيربوينت : كانشاء الصلاحيات و القوائم و انواع المحتوى ...
|
نعم
|
*
|
نعم
|
*
|
*: لا اقصد هنا بالنجمة الحمراء ان الحالة غير ممكن لكن ليست الافضل من حيث سهولة الاستخدام.
* حسب طريقة الرفع او نوع الحل البرمجي المراد انتاجه :
.NET
|
JavaScript
| |||
CSOM
|
REST
|
CSOM
|
REST
| |
Farm Solution
|
نعم
|
نعم
|
نعم
|
نعم
|
SharePoint Hosted Apps
|
لا
|
لا
|
نعم
|
نعم
|
Cloud Hosted Apps
|
نعم
|
نعم
|
نعم
|
نعم
|
Apps for Office
|
لا
|
لا
|
نعم
|
نعم
|
2- لاعتبارات الاداء :
البعض لا يهتم بالاداء او Performance الا اذا فقده :)
فعادة لا يتم الالتفات الى مسالة اداء الاكواد الا بعدما يتم اكتشاف ضعف فيه. و في هذا الاطار اؤكد لك ان الاختبارات اثبتت ان استخدام REST عادة ما يتسبب في ارسال طلبات لخادم الشيربوينت اضعاف مضاعفة مقارنة باستخدام CSOM.
سبب ذلك انك عندما تستخدم REST فانك تضطر للاتصال بالخادم في كل عملية : اذا اردت انشاء قائمة تتصل بالخادم , اذا اردت اضافة عنصر واحد الى تلك القائمة ستتصل بالخادم مرة اخرى و هكذا ...
لكن عن طريق CSOM فان ذلك يتم دفعة واحدة على هيئة BATCH. بطبيعة الحال مثل هذا السلوك من REST يؤثر حتى على موارد الشبكة من حيث الحمل الزائد عليها ...
3- قابلية الاختبار :
هذا الامر مهم جدا حيث نعرف كلنا صعوبة اختبار اكواد CSOM .
اعتقد ان هذا المعيار بالذات يصب في صالح REST. حيث انه اسهل في الاختبار لانك عندما تختبر اكواد REST فانك تختبر الويب المتعارف عليه (طلبات HTTP ...) على عكس CSOM فانك تحتاج التعامل مع شيئيات شيربوينت "SharePoint Objects".
عموما انت تحتاج الى ما يسمى ادوات المحاكات mock tools مثل :
- microsoft fakes
- type mock isolator
- nmock
- just mock
4- حماية الملكية الفكرية :
هذا الامر يهم بالاساس من يقوم بنشر التطبيقات على متجر الاوفيس و شيربوينت.
لا يوجد في الحقيقة الية لحماية اكوادك اذا كانت تعمل على المتصفح حيث ان اي احد بامكانه نسخها بسهولة كما انك عندما تستخدم REST سيصبح من السهل معرفة خدمة الويب التي تقوم باستهلاكها و كذلك جميع مدخلات و مخرجات HTTP التي تصدر عن تطبيقك ...
لكن اذا كنت مجبرا على استخدام SharePoint Hosted App و بالتالي على JavaScript اليك بعض الممارسات التي تجعل من عدم احترام الغير لملكية الفكرية امرا صعبا عليهم :
- بامكانك تعقيد الاكواد باستخدام TypeScript مثلا بدلا من كتابة الاكواد مباشرة عن طريق JaveScript
- استخدم JaveScript Obfuscator
5- اعتبارات المبرمج :
هذا اخر اعتبار من حيث ترتيب الاهمية ليس لاني لا احب المبرمجين , على العكس فانا بالاساس مبرمج :) لكن لانه حسب رايي الشخصي لابد للمبرمج ان يتاقلم مع اي لغة يطلب منه التعامل معها.
- نحن نعلم ان CSOM هو اسلوب من انتاج مايكرسفت لذلك اذا حاولت استخدام اسلوب اخر , لا اقول انك لا تستطيع تنفيذ ما تحتاج لكن ستحتاج غالبا الى عمل اضافي.
- حاليا لا يمكنك ان تتعامل مع اجراءات العمل في شيربوينت 2013 (workflows) و خدمة Managed Metadata الا من خلال CSOM لان نقاط REST التي يوفرها شيربوينت حاليا لا يمكنها الاتصال بهذين المكونين .
- اضف الى ما سبق ان قلة الموارد التعليمية الخاصة بـ REST قد تجعل الكثير لا يفضله.
- عدم الرغبة في تعلم REST مع اني اعتقد ان المبرمج لابد ان يكون لديه الرغبة في تعمل الجديد دائما.
الخاتمة:
من يقول ان مستقبل البرمجيات على شيربوينت و غيره في REST مخطأ , قد يكون ذلك صحيحا خارج شيربوينت لكن مع شيربوينت يوجد استثمار كبير جدا من مايكرسفت في CSOM ... و لا اظنهم ستغنون عنه بسهوله !!
ليست هناك تعليقات:
إرسال تعليق