الاستجابة.الكتابة مقابل <%= %>

Question

مع الأخذ في الاعتبار أن هذا هو ل أسب الكلاسيكية

أيهما أفضل، كل HTML موجود في عبارات Response.Write أو إدراج متغيرات في HTML عبر <%= %>.
على سبيل المثال

Response.Write "<table>" & vbCrlf
Response.Write "<tr>" &vbCrLf
Response.Write "<td class=""someClass"">" & someVariable & "</td>" & vbCrLf
Response.Write "</tr>" & vbCrLf
Response.Write "</table>" & vbCrLf

ضد

<table>
  <tr>
     <td class="someClass"><%= someVariable %></td>
  </tr>
</table>

أنا أسأل بشكل أساسي من وجهة نظر الأداء التي سيكون لها أقل تأثير على الخادم عندما يكون هناك متغيرات متعددة لإدراجها؟

إذا لم تكن هناك اختلافات فنية، فما هي الحجج لصالح أحدهما على الآخر؟

Answer 1

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

على أية حال، لا يهم.في نهاية المطاف، كل ما يفعله ASP هو مجرد تنفيذ برنامج نصي!يأخذ المحلل اللغوي ASP الصفحة، ويقوم بتحويلها <%= expression %> في استدعاءات البرامج النصية المباشرة، وتصبح كل كتلة متجاورة من HTML بمثابة استدعاء ضخم لـ Response.Write.يتم تخزين البرنامج النصي الناتج مؤقتًا وإعادة استخدامه ما لم تتغير الصفحة على القرص، مما يؤدي إلى إعادة حساب البرنامج النصي المخزن مؤقتًا.

الآن، الكثير من الاستخدام <%= %> يؤدي إلى الإصدار الحديث من "كود السباغيتي":"حساء العلامة" اللعين.لن تكون قادرًا على تكوين رؤوس أو ذيول للمنطق.من ناحية أخرى، الاستخدام المفرط لـ Response.Write يعني أنك لن تتمكن أبدًا من رؤية الصفحة على الإطلاق حتى يتم عرضها.يستخدم <%= %> عندما يكون ذلك مناسبًا للحصول على أفضل ما في العالمين.

قاعدتي الأولى هي الانتباه إلى نسبة "النص المتغير" إلى "النص الثابت".

إذا كان لديك عدد قليل من الأماكن التي تحتوي على نص متغير لاستبداله، فإن <%= %> بناء الجملة مضغوط للغاية وسهل القراءة.ومع ذلك، كما <%= %> تبدأ في التراكم، فهي تحجب المزيد والمزيد من HTML وفي نفس الوقت تحجب HTML المزيد والمزيد من المنطق الخاص بك.كقاعدة عامة، بمجرد أن تبدأ في التعامل مع الحلقات، عليك التوقف والانتقال إلى Response.Write`.

ليس هناك العديد من القواعد الصعبة والسريعة الأخرى.يتعين عليك أن تقرر بالنسبة لصفحتك الخاصة (أو قسم من الصفحة) أيها أكثر أهمية، أو الذي يصعب فهمه بشكل طبيعي، أو الأسهل في كسره:المنطق الخاص بك أو HTML الخاص بك؟عادةً ما يكون أحدهما أو الآخر (لقد رأيت مئات الحالات لكليهما)

إذا كان منطقك أكثر أهمية، فيجب أن تزن أكثر Response.Write;سيجعل المنطق يبرز.إذا كان HTML أكثر أهمية، تفضل <%= %>, مما سيجعل بنية الصفحة أكثر وضوحًا.

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

Answer 2

من وجهة نظر التفضيل الشخصي أفضّل الطريقة <%= %> لأنني أشعر أنها توفر محتوى متغيرًا أفضل لفصل المحتوى الثابت.

Answer 3

بغض النظر عن مشكلات سهولة قراءة/صيانة التعليمات البرمجية التي تناولها الآخرون، كان سؤالك يتعلق على وجه التحديد بالأداء عندما يكون لديك متغيرات متعددة لإدراجها - لذلك أفترض أنك ستكرر شيئًا مثل جزء التعليمات البرمجية الخاص بك عدة مرات.في هذه الحالة، يجب أن تحصل على أفضل أداء باستخدام استجابة واحدة. اكتب دون ربط كل الأسطر الجديدة:

Response.Write "<table><tr><td class=""someClass"">" & someVar & "</td></tr></table>"

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

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

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

Response.Write "<table>" _
        & "<tr>" _
            & "<td class=""someClass"">" & someVar & "</td>" _
        & "</tr>" _
        & "<tr>" _
            & "<td class=""anotherClass"">" & anotherVar & "</td>" _
        & "</tr>" _
        & "<tr>" _
            & "<td class=""etc"">" & andSoOn & "</td>" _
        & "</tr>" _
    & "</table>"

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

ما إذا كانت مكاسب الأداء تستحق العناء أو ما إذا كان من الأفضل لك توسيع نطاق أجهزتك، فهذا سؤال منفصل - وبالطبع، ليس هذا خيارًا دائمًا.

تحديث: راجع النصائح 14 و15 في مقالة MSDN هذه بقلم Len Cardinal للحصول على معلومات حول تحسين الأداء باستخدام Response.Buffer وتجنب تبديل السياق: http://msdn.microsoft.com/en-us/library/ms972335.aspx#asptips_topic15.

Answer 4

تشير العديد من الإجابات هنا إلى أن الطريقتين تنتجان نفس المخرجات وأن الاختيار يعتمد على أسلوب الترميز والأداء.يبدو أنه من المعتقد أن المحتوى الثابت خارج <% %> يصبح استجابة واحدة.

ومع ذلك، سيكون من الأكثر دقة القول بأن الكود الموجود خارج <% %> يتم إرساله باستخدام BinaryWrite.

يأخذ Response.Write سلسلة Unicode ويقوم بتشفيرها إلى Response.CodePage الحالي قبل وضعها في المخزن المؤقت.لا يتم إجراء مثل هذا التشفير للمحتوى الثابت في ملف ASP.يتم تفريغ الأحرف الموجودة خارج <% %> حرفيًا بايت للبايت في المخزن المؤقت.

ومن ثم، حيث يختلف Response.CodePage عن CodePage الذي تم استخدامه لحفظ ملف ASP، فقد تختلف نتائج الطريقتين.

على سبيل المثال لنفترض أنني قمت بحفظ هذا المحتوى في صفحة الرموز القياسية 1252:-

<%
     Response.CodePage = 65001
     Response.CharSet = "UTF-8"
 %>
<p> The British £</p>
<%Response.Write("<p> The British £</p>")%>

الفقرة الأولى مشوهة، حيث لن يتم إرسال £ باستخدام ترميز UTF-8، أما الثانية فهي جيدة لأن سلسلة Unicode المقدمة مشفرة إلى UTF-8.

وبالتالي، من وجهة نظر الأداء، يُفضل استخدام المحتوى الثابت نظرًا لأنه لا يحتاج إلى تشفير ولكن يلزم توخي الحذر إذا كانت صفحة الرموز المحفوظة تختلف عن صفحة الرموز الناتجة.لهذا السبب أفضّل الحفظ بتنسيق UTF-8، مع تضمين <%@ codepage=65001 وتعيين Response.Charset = "UTF-8".

Answer 5

أفضّل الطريقة <%= %> في معظم المواقف لعدة أسباب.

1. يتعرض HTML لـ IDE بحيث يمكن معالجته مما يمنحك تلميحات الأدوات ، وإغلاق العلامات ، إلخ.
2. يعد الحفاظ على المسافة البادئة في الإخراج HTML أسهل مما قد يكون مفيدًا للغاية في تخطيط إعادة صياغة.
3. خطوط جديدة دون إلحاق VBCRLF على كل شيء ومرة ​​أخرى لمراجعة مصدر الإخراج.

Answer 6

سيعرض تنسيق الاستجابة HTML كما يلي:

<table>
<tr>
<td class="someClass">variable value</td>
</tr>
</table>

ونتيجة لذلك، لن تكون وسائل إنتاج التعليمات البرمجية الخاصة بك غير قابلة للقراءة فحسب، بل سيتم أيضًا تبويب النتيجة بشكل غير مناسب.التزم بالخيار الآخر.

Answer 7

أنا أفضل <%= %> فقط لأنه يجعل تطوير جافا سكريبت أسهل.يمكنك كتابة التعليمات البرمجية التي تشير إلى عناصر التحكم الخاصة بك مثل هذا

var myControl = document.getElementById('<%= myControl.ClientID %>');

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

يمكن لـ Response.Write كسر بعض أكواد ASP.NET AJAX في بعض المناسبات، لذا أحاول تجنب ذلك ما لم أستخدمه لعرض أشياء محددة في عناصر التحكم المخصصة.

Answer 8

أحاول استخدام نموذج MVC عند القيام بـ ASP/PHP.إنه يجعل الأمور أسهل في الصيانة وإعادة البناء والتوسع فيها.وفي هذا الصدد، أميل إلى وجود صفحة تمثل النموذج.إنه في الغالب VB/PHP ويقوم بتعيين vars لاستخدامه لاحقًا في العرض.كما أنه يُنشئ مجموعات كبيرة من HTML عند التكرار لتضمينها لاحقًا في العرض.ثم لدي صفحة تمثل العرض.غالبًا ما يكون هذا HTML مليئًا بالعلامات <%= %>.النموذج هو #include -d في العرض وانطلق بعيدًا.يتم تنفيذ منطق وحدة التحكم عادةً في JavaScript في صفحة ثالثة أو من جانب الخادم.

Answer 9

ASP الكلاسيكي الخاص بي صدئ، ولكن:

Response.Write "<table>" & vbCrlf
Response.Write "<tr>" &vbCrLf
Response.Write "<tdclass=""someClass"">" & someVariable & "</td>" & vbCrLf 
Response.Write "</tr>" & vbCrLf 
Response.Write "</table>" & vbCrLf

يتم تشغيل هذا كما هو.ولكن هذا:

<table>
  <tr>
     <td class="someClass"><%= someVariable %></td>
  </tr>
</table>

النتائج في:

Response.Write"<table>\r\n<tr>\r\n<td class="someClass">"
Response.Write someVariable
Response.Write "</td>\r\n</tr>\r\n</table>"

حيث هو vbCrLf

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

الدعائم لـEuro Micelli - الصيانة هي المفتاح (وهذا أيضًا هو السبب وراء تفوق لغات مثل Ruby وPython وفي الماضي (رغم ذلك....) C# وJava على C وC++ وAssembly - يمكن للبشر الحفاظ على الكود ، وهو أمر أكثر أهمية من تقليل بضع مللي ثانية من تحميل الصفحة.

بالطبع، C/C++ وما إلى ذلك لها مكانها....ولكن هذا ليس هو.:)

Answer 10

<%= %> ويتم توسيع الباقي إلى Response.Write() لذلك هو نفسه في النهاية.

Answer 11

لا يوجد أي تحسين في الأداء عند التبديل إلى Response.Write، ويمكن أن تكون القراءة والصيانة أسرع باستخدام تدوين الاختصار.

Answer 12

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

Answer 13

<%=بازيفاي()%> يكون مفيدًا عندما تقوم بإنشاء HTML من ملف تعبير قصير مضمن مع بعض HTML.

الرد.اكتب "foo" من الأفضل عندما تحتاج إلى القيام ببعض الأشياء HTML مضمن مع الكثير من التعليمات البرمجية.

ومن الناحية الفنية، فهي نفسها.

عند الحديث عن المثال الخاص بك، فإن كود Response.Write يقوم بالكثير من تسلسل السلاسل مع &، وهو بطيء جدًا في VBScript.أيضا، مثل وقال راسل مايرز, ، فهو لا يتم تبويبه بنفس الطريقة التي يتم بها وضع التعليمات البرمجية الأخرى، وهو ما قد يكون غير مقصود.

Answer 14

أنا أتفق مع جيسون, والأكثر من ذلك أن .NET يقدم الآن إطار عمل MVC كبديل لنموذج الويب/Postback/ViewState الفظيع الذي بدأ به .NET.

ربما يكون ذلك لأنني كنت في المدرسة القديمة الكلاسيكية ASP/HTML/JavaScript وليس مبرمج تطبيق سطح المكتب VB الذي تسبب لي في عدم تجويف "طريقة نموذج الويب؟" لكنني مسرور جدًا لأننا نذهب إلى دائرة كاملة وعاد إلى منهجية مثل جيسون يعود الى.

مع وضع ذلك في الاعتبار ، سأختار دائمًا صفحة مضمنة تحتوي على النموذج/المنطق الخاص بك و <٪ = ٪> الرموز داخل القالب الخاص بك بشكل فعال "عرض". سيكون HTML الخاص بك أكثر "قابلية للقراءة" وفصل منطقك بقدر ما يسمح به ASP الكلاسيكي ؛أنت تقتل عصفورين بهذا الحجر.

Answer 15

إذا كان مطلوبًا منك كتابة تطبيق Classic ASP وصيانته، فيجب عليك التحقق من محرك قالب KudzuASP المجاني.

إنه قادر على فصل التعليمات البرمجية وHTML بنسبة 100% ويسمح بالمحتوى الشرطي والاستبدال المتغير والتحكم في مستوى القالب لصفحة asp الأصلية.تتوفر علامات If-Then-Else وTry-Catch-Finally وSwitch-Case وغيرها من العلامات الهيكلية بالإضافة إلى العلامات المخصصة المستندة إلى صفحة asp أو في المكتبات القابلة للتحميل ديناميكيًا (ملفات تعليمات برمجية asp). يمكن تضمين العلامات الهيكلية ضمن هيكلية أخرى العلامات إلى أي المستوى المطلوب.

من السهل كتابة العلامات المخصصة ومكتبات العلامات ويمكن تضمينها على مستوى التعليمات البرمجية لصفحة asp أو باستخدام علامة التضمين على مستوى القالب.

يمكن كتابة الصفحات الرئيسية عن طريق استدعاء محرك القالب على مستوى الصفحة الرئيسية والاستفادة من محرك القالب الفرعي الثاني لأي محتوى داخلي.

في KudzuASP، تحتوي صفحة asp الخاصة بك على تعليمات برمجية فقط، وتقوم بإنشاء محرك القالب، وإعداد الشروط الأولية واستدعاء القالب.يحتوي القالب على تخطيط HTML.بمجرد أن تستدعي صفحة asp القالب، فإنها تصبح بعد ذلك موردًا يحركه الحدث ويعتمد بشكل كامل على تقييم القالب والبنية التي يحتوي عليها.