it-swarm.asia

مزايا / عيوب تطبيقات الويب "المنفصلة"

أنا بصدد تصميم تطبيق ويب PHP/MySQL كبير إلى حد ما. لقد جئت إلى مفترق الطرق بقدر ما العمارة الداخلية. يمكنني إنشاء موقع الويب كتطبيق ويب "تقليدي" حيث ، عندما تقوم بتقديم طلب ، يقوم الخادم بإنشاء صفحة HTML ، أو يرسل لك الصفحة بأكملها ، ويقوم المستعرض بعرضها ، أو ، يمكنك إنشاءها كـ "منفصل" "تطبيق ويب حيث يتم توفير بنية HTML بالكامل ورمز التطبيق إلى المستعرض عند التحميل الأولي ، ويستخدم التطبيق عمليات رد اتصال جافا سكريبت JavaScript للحصول على بيانات أو أوامر مشكلة محددة عبر واجهة برمجة تطبيقات موحدة. وأعتزم أيضًا أن تكون هناك إصدارات متعددة من الموقع (سطح المكتب ، الجوّال ، هاتف iPhone/Android ، محرك بحث سهل الاستخدام ، وما إلى ذلك) وفي مرحلة ما ، ربما حتى تطبيقات الهاتف المحمول أو سطح المكتب المستقلة أيضًا.

ما هي المزايا/العيوب التي واجهتك ، كمطورين للويب ، مع كل من هذه البنى؟ هل هناك سبب واضح لماذا يجب أن أذهب مع واحد على الآخر؟ هل هو أكثر من شيء تفضيل للمطورين؟

3
Adam Maras

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

أيضًا ، يمكن أن تكون المواقع غير المتزامنة بطيئة أو أبطأ من المواقع العادية. عادة ، يتم إضافة هذا النوع من الوظائف لسبب ما ، على وجه التحديد لتجربة المستخدم المخصب. يميل استخدام جافا سكريبت إلى إيذائك على مُحسّنات محرّكات البحث لأن لا يُمكّن مروِّج الويب من فهم هدف جافا سكريبت تمامًا وبالتالي يتجاهلونها في الغالب.

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

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

4
Ben Hoffman

أعتقد أن فكرة تطبيق "منفصل" تعتمد بشكل كبير على JavaScript/AJAX ستقودك بالكثير من المتاعب. بعض الأشياء خارج قمة رأسي:

  1. سيكون الأمر سيئًا بالنسبة إلى مُحسّنات محرّكات البحث لأن Google ستواجه صعوبة في فهرسة أي شيء.
  2. سيكون من الصعب جعلها "مرجعية"
  3. سيكون لديك وقت صعب مع الأجهزة المحمولة حيث أن العديد منها لديها دعم جافا سكريبت محدود للغاية (أو مكسور).
5
Eric Petroelje

أولاً ، لا جريمة إذا كانت هذه الإجابة واضحة جدًا أو أساسية. استخدامك لـ "مفصول" بدلاً من مصطلحات مثل Ajax أو jQuery يجعلني أفترض تجربة أقل مع هذا الموضوع. بالطبع قد أكون قد أساء قراءة السؤال ، لذا اعتذاري إذا كان هذا هو الحال.

استخدم كلاهما ولكن بحكمة

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

ما ينتمي جانب الخادم؟

(هذا مثال صارخ لتوضيح هذه النقطة.) قل أنك تكتب تطبيق ويب يقوم ببعض أنواع البحث. لا تكتب Javascript من جانب المتصفح للاتصال بخدمة ويب من جانب الخادم PHPلاسترداد قاعدة بيانات كاملة بسعة 2 جيجابايت "لتحرير خادمك" وإلغاء تحميل البحث إلى جهاز المستخدم. ما تفعله هو الحصول على مصطلحات البحث من المستخدم مع نموذج ، POST تعيدها إلى الخادم للاستعلام عن قاعدة البيانات مباشرةً ، ثم إرسال النتائج مرة أخرى من الخادم إلى المستعرض.

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

ما ينتمي في المتصفح؟

الرمز الجانبي للمتصفح هو سيناريو "منفصل" (إذا فهمت بشكل صحيح). ولكن لكي يفعل المستعرض أي شيء ذكي ، يجب أن يكون لديه تعاون في الخادم.

حسنًا ، لديك تطبيق البحث الخاص بك يعمل ولكنك تريده مع بعض السراويل الفخمة Ajax. اكتب PHPخدمة ويب _ لأخذ بعض الحروف وإرجاع مصطلحات البحث المتطابقة ، a la ميزة "اقترح البحث" في Bing و Google وما إلى ذلك. اكتب يشير رمز المتصفح الخاص بك إلى المصطلحات فقط بعد كتابة المستخدم بثلاثة أو أربعة أحرف ، لذلك تكون قائمة الإقتراحات صغيرة. مرة أخرى على الخادم ، فهرسة قاعدة البيانات الخاصة بك في هذا المجال حتى يكون البحث سريعًا بسرعة.

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

أين المنطقة الرمادية؟

هنا مرة أخرى انها دعوة الحكم. أعلاه ، تحدثت عن الخادم الذي يقوم بالبحث ، ثم أرسل النتائج إلى المتصفح. لكن السؤال الذي يطرح نفسه ، هل تسمح للمتصفح بإرسال مصطلحات البحث مع النموذج وجعل الخادم يعرض صفحة النتائج ، أم أنك تستخدم Ajax/Javascript من جانب العميل لإرسال مصطلحات البحث واسترجاع النتائج ، ثم تقديمها في DIV لتجنب تحديث الصفحة؟ كلاهما صالح. من ناحية الموارد ، ليس هناك فائدة حقيقية في كلتا الحالتين. يمكن لطريقة Ajax أن توفر تجربة مستخدم أفضل ، لكن وفقًا لتطبيقك والظروف ، قد تطرح بعض التحديات الأخرى (مثل الأمان).

الحد الأدنى

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

2
b w

لتتمكن من إعادة استخدام الكود ، يمكنك دائمًا النظر إلى XSLT لإنشاء الصفحات المقصودة ومن ثم الحصول على واجهات XML/JSON لـ AJAX (باستخدام واجهة XML لصفحات XSLT المقصودة).

عادة ما تسمح للمحتوى والتفاعل بالعمل على واجهة RESTful مع بادئة/json/... و/xml/... واستضافة المحتوى الرئيسي الخاص بك ، وتحويلها إلى ترميز عبر XSLT on/...

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

تحتاج مواقع الويب للجوّال في بعض الأحيان إلى تخطيطات مختلفة (مخصصة لمواقع iPhone فقط أي شخص؟) يمكن لتحويل XSLT بسيط هنا أو هناك لعملاء مستخدمين مختلفين إعادة استخدام كل ما قمت به حتى الآن.

تذكر أن التصميم من أجل إخراج HTML بسيط والتنقل ، يمكن أن تتبع التبسيط AJAX.

PS - هل جانب خادم تحويلات XSLT

1
Metalshark