Насколько мощен тег <script>в ASP.NET?

Question

Я новичок в веб-разработке с .NET, и в настоящее время я изучаю страницу, на которой у меня есть как отдельные разделы кода (в моем случае файл .CS, связанный с файлом ASPX), так и код, который находится внутри ASPX-файл внутри тегов, подобных этому:

<script runat="server">
//code
</script>

Q1 : В чем главное отличие (помимо логических вопросов, таких как организация, удобочитаемость и т.д.), что можно сделать одним способом, а другим - нельзя? Для чего лучше всего подходит каждый режим?

Q2 : Если я собираюсь разработать простую страницу с подключением к базе данных, импортом библиотеки, доступом к элементам управления (ascx) и доступом к изображениям в других папках ... какой метод выбрать?

Answer 1

Все, что вы можете сделать с помощью кода, вы можете сделать с помощью встроенного скрипта, как вы написали. Но вы все равно должны использовать код позади. Некоторые вещи (например, использование директив) немного проще, и это помогает поддерживать ваш код организованным.

Answer 2

Q1 : Ничего. Помимо того, что вы и другие упомянули (разделение, удобочитаемость), вы можете делать все, что «код позади», может делать с «встроенным» (код внутри самой страницы) кодированием.

Встроенное кодирование не обязательно означает его как «код спагетти», в котором смешаны пользовательский интерфейс и код (как в старой школе ASP). Весь ваш код может жить за пределами UI / HTML, но все еще быть встроенным. Вы можете скопировать / вставить весь код code-behind на свою встроенную страницу и внести несколько корректировок (проводка, пространства имен, объявления импорта и т. Д.), И все.

Другие комментарии попали в точку: мобильность и быстрые исправления / модификации. В зависимости от вашего варианта использования, вы можете не хотеть, чтобы некоторые разделы кода были доступны (проприетарны), но были доступны для использования. Это характерно для профессионалов веб-разработчиков. Встроенный код позволяет вашим клиентам быстро / легко настраивать функциональность так, как они хотят, и могут использовать некоторые из ваших (проприетарных) библиотек (библиотек) в любое время, не прибегая к кодовым джокам (если бы они были, они бы этого не сделали). нанял тебя в первую очередь).

Таким образом, с практической точки зрения это похоже на отправку «html» -файла клиентам, содержащего инструкции о том, как что-то изменить (без разбивки) ... вместо отправки файлов с исходным кодом вместе с html (aspx) страницами и надеясь, что ваши клиенты знают, что с ними делать ....

Q2 : Хотя стиль (встроенный или с выделенным кодом) будет работать, на самом деле нужно смотреть на ваше приложение по уровням. Обычно это будет: пользовательский интерфейс, бизнес-логика и уровни данных. Думая о таких вещах, вы сэкономите много времени.

Практические примеры:

• Если более чем одна страница вашего веб-приложения должна представлять / получать доступ к данным, то лучше всего использовать уровень данных. На самом деле, даже если в настоящее время у вас есть потребность в 1 странице, она, вероятно, никогда не останется такой, поэтому подумайте об этом как о лучшей практике.
• Если более чем одна страница вашего веб-приложения будет собирать данные от пользователей (например, связаться с нами, зарегистрироваться / зарегистрироваться и т. Д.), То вам, вероятно, потребуется подтвердить ввод. Поэтому вместо того, чтобы делать это постранично, общая библиотека проверки ввода сэкономит ваше время и уменьшит объем необходимого кода.

В приведенных выше примерах вы "разделили" большую часть обработки на свои собственные уровни. Ваши отдельные html / aspx-страницы могут затем быстро использовать «библиотеки кодов» (проверка данных и входных данных) с минимальным кодом на «уровне страниц». Тогда решение использовать встроенные или выделенные на уровне страницы стили на уровне страницы не будет иметь большого значения - вы, по сути, «ошарашите» его до того, что вы используете в данный момент.

Надеюсь, это поможет ....

Answer 3

1. Вы можете использовать все то же самое
2. Всегда старайтесь хранить код отдельно, если у вас нет веских причин не

Как ни странно, я использовал <script runat="server"> в коде infront только сегодня! Я сделал это, потому что вам не нужно собирать целое веб-приложение для развертывания исправления, для которого нужен код. Да, это было исправление ошибки;)

Answer 4

Нет разницы между тегом скрипта и кодом позади. Опция code code фактически возникла из-за использования тега script или <% %> из «Classic ASP». Многим разработчикам не нравился тот факт, что их серверный код располагался рядом с кодом пользовательского интерфейса, потому что он делал файл грязным, и это было намного сложнее для людей HTML (веб-дизайнеров или чего-то еще, что вы хотели бы) называть их) разрабатывать на одной странице с разработчиками одновременно.

Большинству людей нравится использовать параметр code behind (на самом деле это считается стандартным способом работы), потому что он поддерживает интерфейс и код отдельно. Это то, что я предпочитаю, но вы действительно можете использовать либо.

Answer 5

Я не говорю, что вы должны когда-либо взламывать живой код ... но есть небольшая гибкость от наличия "кода позади" в виде встроенного скрипта в том, что вы можете взломать изменения без необходимости перестраивать / публиковать сайт .

Лично я никогда не делал этого, но я слышал случаи, когда люди делали это, чтобы исправить ситуацию.

Answer 6

Держите это отдельно. Используйте страницу .aspx для своего макета, используйте страницу .aspx.cs для любого кода, специфичного для страницы, и для предпочтений вытащите доступ к данным / бизнес-логику на свой собственный уровень, что значительно упростит обслуживание / повторное использование в дальнейшем.

---

Небольшое предостережение: ASP.net MVC использует встроенные скрипты в своих представлениях, и я действительно пришел к этой идее - он может сделать простые вещи простыми, но архитектура, используемая в MVC, гарантирует, что ваш бизнес-код остается отдельным из кода вашей презентации.