Веб-сервис VBNet Webforms в качестве посредника Ajax

Question

Я разработчик PHP / Vue.js / jQuery, который только что начал новую работу, где моей первой задачей является очистка проекта Web Forms, написанного на Visual Basic в 2009 году. Я веду с этим, так что если это Звучит бестолково, потому что во многих отношениях это так.

Я ищу создание веб-службы (или чего-то еще), которая будет служить интерфейсом между файлами веб-интерфейса aspx и VB-классами в рамках проекта. Я хотел бы, чтобы javascript-запросы ajax подключались к облегченным промежуточным методам в файле .asmx, которые будут перенаправлять запрос различным классам, выполняющим тяжелую работу. Я думаю, что таким образом я смогу хранить бэкэнд-логику отдельно от интерфейсной логики легко управляемым способом, и они смогут получать вызовы либо от моего веб-сервиса, либо от другого класса vb и отвечать соответствующим образом.

Мои вопросы:

1. Это жизнеспособный / вменяемый способ действовать? Если нет, можете ли вы сказать мне, что не так с моим мыслительным процессом?
2. Если это верно, то:
   1. Можно ли разделить веб-сервис между несколькими файлами
   2. Есть ли у Гоча , о которых я должен знать?

Редактировать: Кроме того - только потому, что я считаю, что это будет лучшим решением, и об этом обязательно нужно подумать: меня попросили не переносить это в MVC / Web API

Answer 1

У WebForms есть файлы с выделенным кодом для этого интерфейса между интерфейсным файлом и файлами, находящимися в области проекта, идея была aspx для пользовательского интерфейса, кодовая часть для бизнес-уровня, которая затем выполняла вызовы либо для дальнейших бизнес-уровней, либона уровне данных.

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

В конечном счете, в этом нет ничего неправильногос тем, что вы описываете.Это все еще жизнеспособная парадигма, она просто не использует преимущества веб-форм, хотя вы все еще ограничены их недостатками.

Тем не менее, я бы, вероятно, не использовал файлы ASMX для того, что выпопытки.ASMX - это « WebServices », и по умолчанию для них используются SOAP и « WebMethods .»

. Вероятно, вы получите лучший опыт, если будете использовать ASHX (универсальные обработчики) для своихAJAX звонит.ASHX вернет все, что вы скажете, и на самом деле не будет поведения по умолчанию.Таким образом, вы можете легко заставить их отвечать JSON или XML.

Исходя из того, что вы описали как свой предыдущий опыт, я догадываюсь о том, что самая большая хитрость, которая вас поймает, заключается в том, что по умолчанию WebForms изменяют ID для серверных элементов управления так, как это необходимо, на основе его родительских элементов.,

Итак, если у вас есть любой из них:

<asp:textbox runat="server" id="txtFoo" />
<input type="text" runat="server" id="txtBar" />

Они не найдут элементы DOM

$("#txtFoo").on("change", function() {alert('hi');});
$("#txtBar").on("change", function() {alert('hi');});

Но они будут

$("#<% Response.Write(txtFoo.ClientId)%>").on("change", function() {alert('hi');});
$("#<% Response.Write(txtBar.ClientId)%>").on("change", function() {alert('hi');});

И чтобы сделать это еще более запутанным, если у вас есть это:

<input type="text" id="txtFooBar" />

Тогда это БУДЕТ найти элемент DOM

$("#txtFooBar").on("change", function() {alert('hi');});

Причина в том, что txtFooBar не является серверным элементом управления,в то время как txtFoo и txtBar есть.