ASP.NET: Код позади или никакой код позади?
Почему кто-либо хотел бы не использовать код позади файла так, чтобы сервер примкнутый код был разделен от разметки? Разве это, как предполагалось, не было одним из преимуществ.NET по классическому ASP?
Лично, я думаю, смешивая код с разметкой, делает код намного тяжелее для понимания.
Я очень не хочу видеть, что они чинят <% %> (сервер примкнул блоки), межсоединенный в с разметкой, фу. Я ожидал бы, что это находится в ASP.NET только для обратной совместимости с Классиком ASP, но я вижу примеры от MS все время, которые включают те желтые скобки.
Я пытаюсь понять пример кода, который доступен для скачивания здесь и озадаченный в том, почему любое из моих повреждений со стороной сервера, показанных здесь, не повреждается при выполнении кода даже при том, что я вижу, что это было установлено в web.config. Так как я обычно работаю с кодом-behinds, я задаюсь вопросом, существует ли что-то о серверном коде в aspx, который обрабатывается по-другому, который препятствует тому, чтобы я отладил код runat=server.
Так. Мои вопросы:
1) Почему кто-либо хотел бы не использовать код позади файла так, чтобы сервер примкнутый код был разделен от разметки?
2) То, почему я не мог бы смочь повредиться на сервере, примкнуло логика?
Ваше понимание и мнения также одобрены на любом из моих связанных комментариев.
4 ответа
Возможность использования встроенного кода с помощью <% > обеспечивает не только обратную совместимость, но и функцию .NET, которая позволяет использовать некоторые (относительно!) четкие и простые решения. Однако его часто используют менее чем идеальным способом. Аналогично, код в коде позади, если часто (обычно на самом деле) используется менее чем идеальным способом, как и веб-элементы управления.
Наличие кода в коде позади обычно не служит для отдельных проблем , но для того, чтобы перепрыгивать код спагетти в другом месте, чем мы имели его в классическом asp. .NET действительно позволяет вам иметь очень хорошо организованные решения, но это зависит от вас, чтобы это произошло. Наличие кода в коде за страницами является не первым шагом в этом путешествии, как раз там, где это путешествие может начаться.
Что касается того, почему ваши события не запускаются, скорее всего:
- Событие на самом деле не инициируется. (Вы изменяете выбранный предмет в выпадающем списке, чтобы фактически инициировать это событие?)
- У вас на самом деле нет проводной связи события. В окне свойств этого элемента управления указано имя функции события, соответствующее рассматриваемому событию? (это самый простой путь; вы также можете использовать дескрипторы в vb, например)
- Часто, когда мои события не запускаются, это потому, что я делаю что-то глупое, как не запустив мой код, или мой url указывает на неправильное место.
1) Я думаю, если вы используете для разработки классического ASP, то его легкий переход.
2) Не видение своей разметки, я бы не смог сказать вам, какова ваша проблема. Если вы не ударять, что точки останова, не может быть одна из нескольких причин:
- Отладка может быть отключена
- Это событие не происходит
- Там нет ничего в разметке говорит, что контроль вашего метода Есть в качестве обработчика для мероприятия.
Кронштейны, используемые в большинстве примеров MS, обычно предназначены для вызовов функций или ссылки на Databilder.
Например, <% # Databilder.eval («MyColumn»)%> будет использоваться в ретранслятере.
Есть также теги, которые используются для отсчета web.config атрибуты как строки соединения <% $ ConnectionStrings: NorthwindConnection%>
Очень часто «образец» ASP.NET кода распределяется с помощью встроенного кода просто потому, что его проще распространять. Он автономный, его можно просто скопировать и вставить в блокнот, сохранить в виде .aspx в папке для тестового сайта и посмотреть, как он работает. Это, наверное, не то, чем ты хочешь заниматься на производстве.
Что касается более общего вопроса... ASP.NET MVC технически все еще ASP.NET и не использует файлы с кодом. Многие разработчики считают, что файлы с кодом позади просто торговали одним типом уродства для другого; Лично я могу видеть это с обеих сторон, но я думаю, что реальной причиной такого большого количества паршивого кода в классическом ASP был не суп с тэгом, а тот факт, что люди делали безумные вещи в «видимом» коде, такие как открытие подключений к базе данных. До тех пор, пока вы не делаете такого рода вещи, несколько серверных тэгов не является большой проблемой.
На самом деле, если вы выполняете привязку данных, у вас будет куча Eval и Bind тэгов, смешанных с разметкой. Так что даже чистая WebForms с кодом позади не всегда чиста.