ما هي أبسط طريقة لتحويل خدمات ODATA لخدمات بيانات WCF إلى واجهة برمجة تطبيقات الويب؟

Question

أنا أبحث حاليًا في جدوى تحويل خدمات ODATA الحالية لـ WCF Data Services إلى Web API Odata.

أنا مرتبك قليلاً في تطبيق Odata لـ Web API. من خلال خدمات بيانات WCF ، يجلس على الجزء العلوي من نموذج كيان ado.net الخاص بنا والذي يكشف مجموعة من الجداول من الواجهة الخلفية لخادم SQL ، أي أنك تعطي WCFDs نموذج ADO لتوليد وبعد ذلك يمكنك الوصول إلى جميع الجداول من خلال المعيار بناء جملة Odata.

مع API على الويب من جميع القراءة حتى الآن ، هل نقوم بإنشاء وحدة تحكم أو إجراءات منفصلة لكل جدول/كائن نريد فضحه؟ هل فاتني شيء؟ هل هناك مجرد طريقة يمكن أن تعرض وحدة التحكم في واجهة برمجة تطبيقات Web Web Odata فقط الكشف عن النموذج بأكمله من نموذج بيانات ADO؟ الاضطرار إلى إنشاء إجراء لكل طاولة سيكون فوضى وبائسة.

حاليًا إذا احتجنا إلى إضافة جدول ، فإننا نخطط فقط في EDMX وسيقوم WCFDs تلقائيًا بفضحه لأنه يتم تعيينه إلى السياق الكامل للنموذج.

Answer 1

توليد النموذج (ق)

تستطيع:

• استخدم ال نموذج المؤتمر باني من ASP.NET Web API. هذا يولد نموذجًا مختلفًا عن ما ينتجه منشئ نماذج الاتفاقية الخاص بـ EF: edmlib IEdmModel. نرى هذا السؤال على الرغم من أنك تستخدم النموذج الأول أو قاعدة البيانات الأولى. تبدو هذه الطريقة للخلف حقًا ، وهي كذلك ، لكنها تعمل في الغالب.
• تسلسل نموذج EF وإعادة بنائه على أنه IEdmModel (نرى هذا السؤال). مرة أخرى هذا غير فعال حقا. إذا كنت تستخدم الطراز الأول أو قاعدة البيانات الأولى ، فستحتاج فقط إلى إلغاء تمييز ملف EDMX لإنشاء IEdmModel. لا يزال ينتج طرازًا مختلفًا داخليًا ، ولكن على الأقل CDSL هو تنسيق أكثر استقرارًا من اتفاقيات رمز CLR ، لذلك من المحتمل أن يكون لديك مفاجآت أقل مما ستحصل عليه عند استخدام اثنين من بنات النماذج القائمة على المؤتمرات.

والسبب في ذلك هو أن ملحقات ASP.NET Web API Odata تستخدم EDMLIB ، بينما تستخدم EF الكود الخاص بها ، و لا توجد خطة لجعلهم يعملون معًا. ربما ستجد هذا التشدق مفيد إذا كنت فضوليًا.

العمل على واجهة برمجة التطبيقات

بمجرد إنشاء النموذج من مصدر فريد (بحيث يمكنك العمل على النموذج الخاص بك من مكان واحد) ، سيكون عليك بالفعل إنشاء وحدة تحكم لكل كيان ، بشكل أساسي. لا تتمثل نقطة واجهة برمجة تطبيقات الويب في بناء الأشياء بشكل تلقائي ، ولكن لتقديم المرونة للمطور. ال EntitySetController يساعد على تقليل التكرار ، لكنه لن يقدم كل شيء خارج الصندوق.

أخذ خطوة إلى الوراء

في التشدق المذكور أعلاه ، أتحدث أيضًا عن الفرق بين أ طبقة الخدمة API و A. طبقة البيانات API. ASP.NET Web API أكثر ملاءمة للخدمات ، في حين أن Odata تجعل الخدمات محرجة. من ناحية أخرى ، تجعل Odata من الوصول إلى نسيم (كونه بشكل أساسي مثل SQL المريح) وبموجب إرفاقه مباشرة بنموذج البيانات ، يمكن أن يؤدي إلى أتمتة الكثير من الأشياء كما رأيت مع خدمات بيانات WCF. ASP.NET WEB API مع امتدادات ODATA تقع في الوسط ، ولا يتم الاتفاق على قيمتها عالميًا (باستخدام أجزاء معينة من بناء جملة Odata URI على واجهات برمجة تطبيقات الخدمة أمر مفيد بالتأكيد).

لا تتناقض مع الطنانة الحديثة حول API API ASP.NET ، فإن خدمات بيانات IT و WCF مختلفة تمامًا وتشغيلها على طبقات مختلفة في التصميم الخاص بك. في الواقع ، في بنية متعددة المستويات ، يمكنك رؤية واجهة برمجة تطبيقات خدمة تم تصميمها باستخدام ASP.NET Web API على رأس واجهة برمجة تطبيقات ODATA التي تم تصميمها باستخدام خدمات بيانات WCF.

نصيحتي هي التفكير بعناية في ما تحاول إنشاءه ، واعتمادًا على الإجابة ، إما اختيار API ASP.NET وتبني حقيقة أن واجهة برمجة التطبيقات التي تعرضها ستكون مختلفة تمامًا عن واجهة برمجة تطبيقات ODATA المتمحورة حول البيانات ، أو العصي مع خدمات بيانات WCF.

خطة ممكنة

يمكنك العثور على الكثير من المواد على الويب حول واجهات برمجة تطبيقات طبقة الخدمة على شبكة الإنترنت من خلال البحث عن مصطلحات مثل "API غير المريح/المريح/Hypermedia API" أو بمقارنة منتجات مثل ServicEstack ، والتي تدافع عن واجهات برمجة التطبيقات الأقل توجهاً إلى البيانات.

إذا كنت لا تزال غير متأكد من طبيعة مشروعك ، النموذج الأولي.

• إذا انتهى بك الأمر بمجموعة من وحدات التحكم المتطابقة بشكل أساسي مع واجهة برمجة تطبيقات الويب ، كل منها تم تعيينه إلى كيان واحد بالضبط ، فإن واجهة برمجة التطبيقات الخاصة بك موجهة نحو البيانات بشكل كبير. اذهب مع خدمات بيانات WCF.
• إذا انتهى بك الأمر مع الكثير من إجراءات ODATA والكيانات المحرجة مع خدمات بيانات WCF ، فأنت بحاجة إلى المزيد من منطق المجال على جانب الخادم من واجهة برمجة التطبيقات ، ولا يوفر لك توجيه البيانات ما يكفي. اذهب مع ويب واجهة برمجة التطبيقات. هناك قاعدة جيدة من الإبهام هنا هي معالجة تصرفات Odata تمامًا كما تعامل الإجراءات المخزنة في DBMS SQL. في الواقع ، تعامل مع أي خادم ODATA باعتباره DBMS ، لأن هذا ما هم عليه. إذا لم تضعها خلف واجهة SQL ، فلا تضعها خلف واجهة Odata.

مهم (تحديث)

تم الإعلان عنه في 27 مارس 2014 أن خدمات بيانات WCF ستكون توقف بواسطة Microsoft لصالح ASP.NET Web API. للتعامل مع حالات استخدام "طبقة البيانات" التي كشفتها هنا ، قالت Microsoft إنها تخطط لتوسيع ASP.NET Web API. بعض تواصل اجتماعي جهود هي أيضا جارية. ستكون خدمات بيانات WCF أيضًا مفتوحة المصدر في مرحلة ما ، لذلك ليس من المستحيل أن يتم الاستيلاء على مشرف جديد ، على الرغم من أنه غير مؤكد.