Реализация AJAX в MVC php
Реализация AJAX в MVC php
Добрый день! Недавно столкнулся с задачей реализовать AJAX на MVC. Думаю, это является тривиальной задачей и во всех фреймворках реализована, но вот в интернете я не наше того что мне было нужно и пришлось делать самому. Данная задача у меня появилась в учебных и производственных целях. Мой руководитель поручил мне сделать простое web-приложение для отработки возражений клиентов во время телефонного разговора. Нужно было сделать как можно быстрее, приложении должно было быть максимально шустрым и без перезагрузок. Так как я не овладел пока ни какими фреймворками для создания SPA то решено было сделать на MVC с использованием AJAX и Jquery, тем более что мне это очень интересно.
Принцип работы моего роутера
Роутер подключает файл с роутами и получает путь, введённый в адресной строке. Далее он проходит по роутам и сопоставляет его с адресом. Если он находит совпадение, то подключает соответствующий класс и вызывает метод и передаёт параметры.
Пример:
Если мой роутер получит путь view-ajax.php то подключит класс (php) AjaxController (ajax) и использует его метод actionMakeAjax (MakeAjax)
Jquery обращения к AJAX
Пример:
Код класса AjaxController
AjaxController содержит единственный метод actionMakeAjax. В нём я получаю название action’а и получаю остальные переданные параметры. Далее я подключаю модель(класс) makeAjax.php в котором содержаться все функции, которые могут быть в вызваны по AJAX.
Модель makeAjax()
Пример:
Для ‘action’: ‘AddNotes’ метод класса makeAjax() будет назван makeAddNotes()
Это пример для ‘action’: ‘GetPost ‘
Этот метод печатает детальный текст записи по её id. У вас может быть любая другая функция, которая вам нужна. Главное, что вы сможете расширять вашу модель и без проблем пользоваться AJAX в MVC.
Если что-то непонятно задайте вопрос в комментариях!
Поддержи Xakplant
Я давно хочу развить видеоверсию, но пока этого не получается из-за нехватки ресурсов. Сейчас я собираю деньги на новый компьютер и микрофон. Поддержи xaklant и ты увидишь полезные видео быстрее.
Обработка ajax запросов в mvc структуре
Столкнулся с проблемой и никак не могу продумать логику работы. На данный момент я использую mvc структуру. Все работает как нужно данные поступают в контроллер, затем отправляются в модель, обрабатываются, возвращаются обратно и выдаются клиенту. Все просто. Но никак не могу придумать, как правильно настроить работу ajax запросов. Их у меня будет очень много. Один из вариантов это создать единый ajax контроллер, на который будут поступать все запросы и там обрабатываться. Но я хочу сделать, чтобы обработка происходила непосредственно в активном контроллере и данные бы обрабатывались в активной модели.
То есть тут мы выводим все новости на странице. Как сюда можно внедрить ajax запрос, точнее как его тут обрабатывать. Если я хочу допустим сортировать не по ид, а по названию.
Вот скрипт отправки:
Меня интересует как правильно по такой структуре сделать обработку ajax запросов и правильно ли я вообще делаю? Возможно есть решения куда лучше этого. Заранее спасибо!
1 ответ 1
Один из вариантов это создать единый ajax контроллер, на который будут поступать все запросы и там обрабатываться.
Нет, так делать не нужно. Обычно, в том же laravel роуты разделены, и это сделано как минимум по 2-м причинам:
Исходя из выше сказанного, сделаем небольшой итог: 1 Controller может иметь много методов, а значит, может обрабатывать много запросов. Каждый метод Controller обрабатывает 1 роут. Как правило, Controller имеет CRUD методы какой-то entity.
У каждого метода класса есть свой http метод:
Как видно из примера, Controller относиться к entity User, а все его методы к действию над этой entity.
По такому принципу работает api в framework-ках (возможно с небольшими отличиями в конкретно взятому framework-у).
То есть тут мы выводим все новости на странице. Как сюда можно внедрить ajax запрос, точнее как его тут обрабатывать.
Если я хочу допустим сортировать не по ид, а по названию.
повторюсь: вторая часть вопроса очень абстракта, и можно там рассуждать много. Определитесь с бизнесовыми задачами, и задавайте конкретный вопрос, если они у Вас еще есть.
Итог: по бекенд части, постарался в кратце описать как устроена api. Очень упрощено, так как не сказано про middleware, Rate-Limit, CORS и т.д.
Вызов функции php в MVC с использованием AJAX?
В настоящее время я перемещаю уже созданное веб-приложение в MVC и выясняю, что я слишком новичок, чтобы вносить какие-то изменения. Есть несколько вызовов ajax, которые меня бесят. Я постараюсь быть максимально ясным, но из-за своей неопытности я не уверен, не дам ли мне кстати важную информацию.
Дело в старом приложении, дела идут так:
Здесь возникает моя проблема, и, поскольку у меня больше нет файла userpost.php, я должен отправить его в index.php и вызвать компонент user с помощью петиции get, которая мне не нравится, но я не могу не могу найти другой способ сделать это. И, что еще хуже, я вообще не знаю, как ajax получает необходимые ему переменные. Это должно быть довольно простой ошибкой, но я признаю, что мои навыки на данный момент не так хороши. Вот что я делаю в своей версии:
Буду признателен за любую помощь, и если есть какая-то дополнительная информация, которую я пропустил, пожалуйста, дайте мне знать. Заранее спасибо.
Я добился определенного прогресса, но, похоже, не нашел реального решения. Теперь я знаю, что URL-адрес должен быть контроллером, поэтому я использую «components / userpost / controller.php», и он достигает вызова ajax, потому что появляется предупреждение об успехе. Проблема в MVC, потому что я посылаю ajax на контроллер, но, поскольку у меня нет перезагрузки на странице, все включения не выполняются, поэтому они явно не загружаются, и я получаю ошибки, подобные этой:
Предупреждение PHP: include (components / userpost / model.php): не удалось открыть
поток: нет такого файла или каталога в
/var/www/html/viewer_mvc/components/userpost/controller.php в строке 3,
реферер: Http: //localhost/viewer_mvc/index.php
Очень надеюсь, что вы, ребята, сможете показать мне, где я терплю неудачу, и есть ли особый способ сделать это в MVC.
Решение
Для вызова JQuery он делает запрос POST для index.php?option=users с данными JSON. Форма с удостоверением личности userForm сериализуется с помощью Jquery serialize метод.
Теперь для вашего примера PHP
Чтобы начать его реализацию, вам нужно добавить логику, чтобы он проверял переменную POST, если вы не используете код платформы. Так что если у вас есть элемент формы с именем name, он будет доступен в вашей переменной POST PHP-скрипта
unboxIT
Если информация была полезной для вас, вы можете поблагодарить за труды Яндекс деньгами: 41001164449086 или пластиковой картой:
Пишем PHP чат ООП MVC Ajax JavaScript
Сразу надо сказать что я не пытаюсь изобрести велосипед, или правильнее сказать чат, благо на сегодня их написано огромное количество. Скорее это проверка собственных навыков приобретённых после прохождения ряда курсов по PHP ООП, программированию, а также изучения JavaScript, помноженных на концепцию MVC. Всё написанное ниже является моим виденьем архитектуры построения web приложения, а именно чата, которое возможно поможет начинающим программистам.
Вступление. Структура приложения чата.
Итак, чат мы будем писать на PHP с использованием ООП в концепции MVC. При отправка сообщений и получение новых будет осуществляться динамически при помощи Ajax POST запросов.
Но прежде чем начать мне бы хотелось сразу показать структуру чата, архитектуру которая у нас выстроится в следующих частях.
Я не буду строить UML диаграммы, поскольку не все с ними знакомы, да и иллюстрация ниже более чем понятна:
Не стоит особо заострять внимание на данной картинке. Она служит лишь для понимания происходящей картины в целом, и к ней следует периодически возвращаться по окончании очередной части, чтобы не запутаться в происходящем.
Часть 1. MVC и файловая структура.
На самом деле самое сложное при написании любого приложения это создание правильной архитектуры. И здесь нам на помощь приходит концепция MVC, которая предлагает разделение приложения на части по функциональному признаку. Соответственно эти части будут находиться в разных файлах и папках организованных соответствующим образом. Именно поэтому мне хотелось бы заострить внимание на MVC чуть более подробнее.
Опишу концепцию MVC коротко, своими словами.
При таком подходе приложение разбивается на три части каждая из которых отвечает за свою сферу, а именно:
Model (Модель) – выполняет обработку данных, вычисления, и т.д.
View (Вид) – отвечает за вид, форму, в общем интерфейс отображаемый пользователю, на основании данных от модели
Controller(Контроллер) – получает данные от пользователя (от интерфейса) и передаёт их соответствующим образом модели.
В соответствие с MVC, и некоторыми другими соображениями структура папок чата будет выглядеть следующим образом:
Часть 2. Начало работы и автозагрузка файлов.
Поскольку я буду использовать PHP ООП подход, то за место скучного подключения нужных файлов через include (require), можно написать функцию которая будет подгружать нужные файлы при инстанцировании класса:
При попытке создать объект класса cMain из пространства имён (namespace) controllers (об этом чуть позже) мы автоматически выполним:
Важно заметить, что функция, str_replace в функции автозагрузчика автоматически заменит ‘\’ на ‘/’, таким образом происходит согласование пространства имён с файловой структурой приложения. Это очень важный момент.
Т.е создавая объект new controllers\cMain, мы фактически выполняем require_once controllers/cMain.
Красиво и изящно, а главное нет длинных имён классов, сложной функции автозагрузки, и файловая структура согласована с пространством имён.
Далее мы выполняем единственный метод request(), который инициализирует работу чата.
Мы только что разобрали работу файла index.php
Небольшое отступление.
Я думаю вы заметили приставку ‘c’ перед названием класса cMain, это говорит о том, что перед нами контроллер. Соответственно ‘m’ – будет означать модель. Для большей простоты и наглядности построения пользовательского интерфейса при помощи шаблонов я не буду использовать ООП, поэтому классов с ‘v’ у меня не будет.
Приставки в виде буквы в названии класса я сделал умышлено, для большей наглядности, и в действительности в этом нет никакой необходимости, поскольку пространство имён однозначно определяют принадлежность того или иного класса в концепции MVC.
Часть 3. Контроллеры.
В чате будет один единственный контроллер, cMain. Его задача, это понять от кого происходит запрос. А именно от JavaScript оставляющей чата, или это первоначальный заход пользователя, который инициализировал выполнение нашего приложения.
namespace controllers;
class cMain<
public function __construct() <
>
Как я говорил ранее, структура папок и пространство имён согласованны, по этому контроллер находится в пространстве имён (namespace) controllers, находясь при этом в папке controllers.
Выполняя в index.php единственный метод request(), мы проверяем наличие POST запросов.
Если POST запроса нет, то, это пользователь первый раз зашёл на страницу, и мы должны показать ему интерфейс, или проще говорят вывести собственно наш чат.
Для этого мы создаём объект сообщений класса mMessagesCheck, передавая в конструктор null (поскольку отсутствует POST запрос). После чего сам объект с сообщениями передаём в конструктор класса mChat, который и отвечает за построение пользовательского интерфейса.
Если же есть POST запрос, то это Ajax запросы, инициированные JavaScript составляющей чата.
Запросы POST могут быть двух видов ‘transmit’ и ‘receive’. Для этого мы просто проверяем наличие соответствующих ключей в глобальном массиве $_POST. Названия ‘transmit‘ и ‘receive‘ выдуманные, но довольно неплохо отражают суть происходящего.
Первый запрос, ‘transmit’, говорит о необходимости добавить новое сообщение, для чего мы выполним в контроллере метод add().
Второй запрос ‘receive’, говорит о желании получить новые сообщения из БД. Здесь мы выполним метод showJson().
Забегая немного вперёд скажу, передавать и принимать сообщения (Ajax запросы), для динамического обновления страницы, мы будем в формате JSON. Не стоит пугаться этого названия, это всего лишь удобный формат представления данных и не более.
В обоих случаях нам потребуется создать объект с сообщениями new mMessagesCheck($_POST). Запрос POST мы передаём в конструктор, поскольку именно в нём будет содержатся информация о вновь добавляемом сообщении от пользователя в БД, либо о желании получить новые сообщения от БД к пользователю.
Крайне важно не возлагать работу моделей (обработку данных, вычисления) на контроллеры. Всё что должен сделать контроллер, это управлять процессом, но не более. В противном случае мы рискуем скатиться к чрезмерному разрастанию контроллера, или говоря научно к Fat Stupid Ugly Controllers (Толстые, тупые, уродливые контроллеры).
Ну да ладно, я отвлёкся, думаю, теперь настало самое время детально рассмотреть, классы модели с сообщениями mMessagesCheck и mMessages.
Часть 4. Модели mMessagesCheck и mMessages.
Сразу хочу сказать, что это самый сложный класс для понимания, поэтому, следует запастись терпением.
mMessagesCheck является прокси для класса mMessages, и оба они по паттерну GOF Proxy реализуют один и тот же интерфейс:
namespace lib;
interface iMessages <
public function __construct($post);
public function get();
public function add();
public function showJson();
>
В конструктор бы будем передавать POST запросы (если они есть).
Метод get() будет возвращать массив сообщений которые есть в БД, для дальнейшей обработки моделью класса mChat.
Метод add() будет добавлять новые сообщения в БД, руководствуясь тем что находиться в POST.
Метод showJson() будет выводить JSON представление сообщений, на основании некоторых параметров, которые опять же находятся в POST.
mMessagesCheck осуществляет проверку данных полученных методом POST, и если они корректны, то передаёт их mMessages для дальнейшего взаимодействия с БД. Таким образом mMessagesCheck как бы защищает mMessages являясь кеширующим защитником. Но оба класса реализуют один и тот же интерфейс.
Итак mMessagesCheck, имеет следующий вид:
Начнём с самого простого, метода get().
Напомню, этот метод вызывается контроллером, если запрос исходит непосредственно от пользователя, т.е. не идёт речи о в взаимодействии данных от пользователя с БД. Поэтому этот метод абсолютно безопасен, и его можно переадресовать дальше объекту класса mMessages:
Важно не забывать вернуть результат полученный непосредственно от модели mMessages с сообщениями, который мы будем позднее использовать в модели класса mChat.
Несколько сложнее работает метод showJson().
В нём проверяется что запрос не пустой, и если это так, то из последовательности символов переданных JavaScript, мы делаем полноценный объект:
В этом объекте при помощи регулярного выражения мы проверяем на корректность одно единственное свойство last. В этом свойстве храниться порядковый номер последнего сообщения которое есть у пользователя. Если это только число, то всё в порядке, и мы также переадресовываем POST запрос объекту класса mMessages.
Здесь нам нет необходимости возвращать запрос, поскольку showJson(), вызывается для того чтобы вывести, показать данные. Именно эти данные увидит JavaScript при соответствующем запросе.
Метод add() работает практически аналогичным образом.
Он принимает POST запрос, делает из него объект. У этого объекта есть 2 свойства user и message, в которых содержится информации о имени пользователя и тексте сообщения которые отправляет пользователь.
Поскольку именно эти свойства (данные) мы будем записывать в БД, их необходимо хорошенько проверить на предмет всевозможных атак, что и делается регулярными выражениями строчками ниже.
В реальности проверка входных данных на атаки должна происходить значительно серьёзнее, но это тема отдельной статьи, или даже книги, и я не хочу углубляться в эти дебри.
Теперь настало самое время рассмотреть класс mMessages.
Именно он занимается взаимодействием (правда через посредников) с БД. Фактически, его основная задача, это подготовить POST данные для записи/получения данных в/из БД в виде SQL запросов и вернуть либо вывести результат.
Итак, собcтвенно код:
Фактически каждый метод в этом классе формирует необходимый SQL запрос для БД, после чего он выполняется, после чего результат возвращается либо отображается. Детально рассматривать SQL запросы не вижу смысла, и хочу остановлюсь лишь на некоторых особенностях класса mMessages.
В конструкторе этого класса:
В переменной $dbConfig будет храниться объект со свойствами, параметрами которые необходимы для подключения непосредственно к БД. Эти свойства мы передадим в конструктор класса mMySQL, который имеет единственный метод request($query), целью которого является выполнение соответствующего SQL запроса $query и возвращение результата.
Также не вижу смысла детально рассказывать о моделях классов mConfigIni и mMySQL, они более чем просты и понятны.
Первый класс mConfigIni, читает конфигурацию из файлов вида ‘свойство=значение’, и формирует объект с искомыми свойствами, которые позднее удобно использовать.
Второй класс mMySQL на основании данных конструктора осуществляет соединение с БД и выполняет запрос при вызове метода request($query).
Хочу обратить внимание на особенность метода add() класса mMessages.
В случае если добавление сообщения прошло успешно, мы отправим сообщение ‘success’.
Это сообщение будет принимать JS, понимая тем самым что сообщение было успешно добавлено в БД.
Почти также работает метод showJson() он берёт сообщения из БД, номера которых больше чем отправил JS (об этом чуть позже). Если таких сообщений нет, то выводиться ‘no’, если есть, то они выводятся в JSON формате для последующей интерпретацией JS:
Часть 5. Модели для создания интерфеса чата, mChat и mTemplate.
Здесь я предлагаю начать с последнего, а именно mTemplate, класс прост и изящен.
Целью данного класса является создание объектов на основании файлов с шаблонами.
Наиболее интересен здесь конструктор. Мы передаём ему 2 параметра, а именно файл с шаблоном на основании какого будет создан объект, и переменные с значениями в виде массива которые будем использовать внутри этого шаблона:
С первым параметром всё понятно, а вот назначение второго параметра в виде массива может несколько озадачить.
Вторым параметром мы передаём массив, ключами которого будут являться название переменных в файле шаблона, а значениями будут значениями переменных.
Проще всего понять это на примере.
Рассмотрим, что произойдёт в конструкторе класса при:
$obj = new mTemplate(‘templates/messages.php’, array(‘messages’=> ‘Много сообщений’)
При выполнение цикла foreach показанного выше в переменную $messages будет записано значение ‘Много сообщений’. Далее мы стартуем буферезованный вывод, состоящий из include файла messages.php.
Для большей простоты, предположим что этот файл представляет из себя что-то вроде:
В этом файле при выполнении переменная $messages получит описанное выше значение.
Т.е. в свойстве готовый HTML код который можно либо использовать дальше, либо показать пользователю. От сюда следуют 2 основных метода:
get() – который вернёт готовый HTML код для последующего использования, например вставки в другой более общий шаблон.
show() – выведет готовый HTML, тем самым передав его браузеру пользователя.
Собственно, именно так и работает mChat:
Этот класс принимает в конструктор единственный параметр – объект сообщений, который мы передали ранее в контроллере cMain.
Далее следует рассмотреть метод show().
В первой строке, мы записываем в переменную $htmlMessages объект с готовым HTML кодом, построенный на основании шаблона ‘templates/messages.php’ и массива сообщений (полученного в результате вызова метода messages->get()).
В messages.php находится шаблон для построения сообщений чата.
Теперь $htmlMessages содержится объект в свойстве html которого, что-то вроде:
Почему в переменную мы не записываем непосредственно HTML код, а объект с свойством, станет понятно чуть ниже.
Аналогично мы поступаем с шаблоном popup.php, который нужен для включения на страницу HTML кода для всплывающих сообщений. А также send.php в котором содержится шаблон для формы отправки данных, в чат.
Самое интересное происходит в предпоследней строке метода:
Здесь мы производим окончательную сборку.
В общий шаблон main.php мы включаем все составные части HTML. Именно для этого мы вызываем методы get(), у соответствующих объектов. Таким образом мы передаём в шаблон main.php составные части HTML кода, но ещё не показываем его пользователю. А вот строка:
Мы показали, отправили готовый HTML код, который будет обработан браузером пользователя.
Схематично иерархию шаблонов можно представить так:
main.php(messages.php + send.php + popup.php)
Детально рассматривать каждый шаблон думаю не имеет смысла, все исходники и ссылка git репозиторий будут в конце. Мне бы хотелось, чтобы была понятна основная суть происходящего.
Об этом мы и поговорим далее.
Часть 6. JavaScript Ajax
На данный момент у нас есть полностью готовая HTML страница, с сообщениями которые есть БД, формой отправки и т.д. Но она полностью статична. Передавать свои сообщения и получать новые от сервера мы будем с использованием JavaScript.
Для этого в шаблонах ранее подключены 3 js файла:
Первый это библиотека Jquery.
По большому счёту она потребуется нам лишь для более удобного формирования Ajax запросов, и для некоторой анимации. Всё это можно сделать и голыми средствами JavaScript, однако Jquery значительно упростит нашу JS составляющую.
Прежде чем переходить непосредственно к рассмотрению JS файлов, надо понимать что у нас в данный происходит в браузере.
А в нем у нас примерно такой HTML код полученный от сервера:
Использование AJAX в ASP.NET MVC
В предыдущих статьях, посвящённых AJAX мы рассматривали стандартные способы реализации данной технологии. Они одинаково подходят не только для PHP или Python, но и для большинства других серверных языков.
Однако у Microsoft, как это часто бывает, свой собственный подход, отличающийся от общепринятого.
В случае Web Forms работа с AJAX построена на основе специальных элементов управления и не составляет сложности в освоении. Но, в ASP.NET MVC помимо написания кода вручную, необходимо владеть целым рядом нюансов, без которых использование AJAX становится крайне сложным.
Если ASP.NET MVC для вас не первая веб технология, забудьте всё, что изучали ранее!
Дело в том, что стандартные методы подходы к реализации AJAX, которые прекрасно работают с тем же PHP, в ASP.NET MVC практически полностью теряют работоспособность.
У Microsoft свой подход!
Подготовка проекта
Для начала необходимо установить специальный плагин для jQuery, который обеспечивает нужный функционал. Это можно без труда сделать с помощью NuGet.
После этого в заголовке страницы или шаблона нужно подключить необходимые библиотеки.
При этом необходимо строго соблюдать последовательность подключения. Вначале подключаем jQuery и только затем плагин (как это показано в примере выше), а не наоборот.
После завершения подготовительных операций можно приступить непосредственно к реализации AJAX.
Реализация серверной части
Для работы с AJAX необязательно создавать отдельный контроллер, можно добавить обработку AJAX запросов к любому из уже имеющихся контроллеров.
В нужном контроллере создадим действие, которое будет выполнять обработку AJAX запроса.
В этом действии мы получаем данные поступившие в запросе и, если это запрос AJAX возвращаем специальное частичное представление, которое в данном случае имеет имя _AjaxTestPartial.
Это представление и есть те данные, которые будут возвращаться в результате запроса.
В представлении, в качестве примера просто выводим некоторый текст и данные переданные из контроллера.
Реализация клиентской части в виде формы
Для создания форм AJAX служит метод BeginForm хелпера Ajax.
Данный метод имеет ряд перегрузок. Чаще всего используется та, что приведена в примере ниже
Важно отметить, что метод BeginForm сам по себе создаёт только «каркас» формы в виде тега form с соответствующими атрибутами. Поэтому наполнение формы элементами управления и обеспечение соответствия их атрибута name параметрам запроса задача разработчика. Обратите внимание, что в приведённом примере внутри фигурных скобок находятся два тега input. Именно так осуществляется наполнение формы функциональными элементами.
Вот как результат работы метода BeginForm выглядит в HTML коде в браузере.
В данном примере при нажатии кнопки (submit)на сервер через AJAX будет отправлено содержимое текстового поля, а в теге p с отображён ответ.
Ответ представляет собой ранее созданное частичное представление. Так как в данном примере серверная часть, по сути, просто возвращает клиенту полученные данные, после слова «Data» будет отображено переданное на сервер содержимое текстового поля.
Важно
Если на странице имеется несколько тегов с id, который указан в параметре UpdateTargetId, то при выполнении запроса будет обновлено содержимое только самого первого из них (ближайшего к началу HTML разметки).
Реализация клиентской части в виде ссылки
Реализация клиентской части в виде ссылки осуществляется при помощи метода ActionLink. Он отличается от метода BeginForm только тем, что вместо каркаса формы генерирует уже готовую ссылку и имеет два дополнительных параметра.
Данный метод также имеет ряд перегрузок. Ниже приведён пример использования наиболее часто используемой из них.
Так приведённая выше AJAX ссылка будет отображаться в HTML коде.
Соответственно, результат работы ссылки:
Другие способы реализации AJAX в ASP.NET MVC
Помимо вышеприведённых хелпер Ajax содержит и другие методы. А, именно:
Но, на практике эти методы используются крайне редко и потому рассматривать их нет смысла.
Параметры AJAX запроса (AjaxOptions)
В ASP.NET MVC можно настроить процесс выполнения AJAX запроса при помощи параметров AjaxOptions.
Один из них UpdateTargetId уже был использован в приведённых примерах. Помимо него также существуют и другие параметры. Вот их полный список:
Данные параметры позволяют производить весьма гибкую настройку.
Например, используя OnSuccess вместо UpdateTargetId можно добиться от метода BeginForm поведения аналогичного функции jQuery post. Что позволяет при необходимости выполнить дополнительную обработку данных перед их отображением на странице.
Заключение
На самом деле использование реализованного в ASP.NET MVC механизма работы с AJAX не представляет особой сложности.
Если необходимо просто вывести готовые данные поступившие с сервера без перезагрузки страницы, всё осуществляется предельно просто без каких-либо дополнительных действий. Достаточно лишь указать куда их следует выводить.
Если же полученные данные требуется предварительно обработать, то здесь также нет ничего необычного. Данные можно передать в обычную функцию обратного вызова на JavaScript и выполнить необходимые операции.
Единственная сложность, с которой может столкнуться новичок, это особенности, обусловленные самой платформой (тот же хелпер Ajax, частичные представления и т.д.). Но, потратив немного времени на освоение, можно её преодолеть.