ASP.NET MVC: Должны Контроллеры, названные Ajax, возвращают JSON или представленный HTML?

Если вы используете JQuery, вам следует использовать JSON или XML, потому что его проще изменить, но если ваш ajax-вызов возвращает только элементы для списка, например, вы также можете использовать html.

Мои личные предпочтения - это JSON или XML, потому что я очень часто использую JQuery

Мне нравится разрешать вызывающему приложению решать. Я собрал вместе MultiViewController (большую часть кода, который я нашел в Интернете, я постараюсь обновить его с учетом имеющихся данных), который на основе расширения действия вернет соответствующий формат. например:

myapp.com/api/Users/1 - defaults to html based on route
myapp.com/api/Users.html/1 - html
myapp.com/api/Users.json/1 - json
myapp.com/api/Users.xml/1 - xml
myapp.com/api/Users.partial/1 - returns a partial view of action name (see code)
myapp.com/api/Users.clean/1 - partial html without styling, etc...

Мои контроллеры наследуются от MultiViewController и вместо «return view (Model);» Я просто называю «вернуть FormatView (Model); или FormatView (« ViewName », Model);». Второе, если мне нужно применить конкретное представление к результату, а не подразумеваемое представление.

MultiViewController выглядит следующим образом. Обратите особое внимание на FormatView, который возвращает результат действия:

    public abstract class MultiViewController : Controller
{
    private const string FORMAT_KEY = "format";
    public enum FileFormat {Html, Json, Xml, Partial, Clean}

    protected MultiViewController()
    {
        RequestedFormat = FileFormat.Html;
    }
    protected FileFormat RequestedFormat { get; private set; }

    protected override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        base.OnActionExecuting(filterContext);
        var routeValues = filterContext.RouteData.Values;
        if (routeValues.ContainsKey(FORMAT_KEY))
        {
            var requestedFormat = routeValues[FORMAT_KEY].ToString();
            if (isValidFormat(requestedFormat))
            {
                RequestedFormat = (FileFormat)Enum.Parse(typeof(FileFormat), requestedFormat, true);
            }
        }
    }

    private bool isValidFormat(string requestedFormat)
    {
        return Enum.GetNames(typeof (FileFormat)).Any(format => format.ToLower() == requestedFormat.ToLower());
    }

    protected ActionResult FormatView(string viewName, object viewModel)
    {
        switch (RequestedFormat)
        {
            case FileFormat.Html:
                if (viewName != string.Empty)
                {
                    return View(viewName,viewModel);
                }
                return View(viewModel);
            case FileFormat.Json:
                return Json(viewModel);
            case FileFormat.Xml:
                return new XmlResult(viewModel);
            case FileFormat.Partial:
            //return View(this.ControllerContext.RouteData.Values["action"] + "Partial");
            return PartialView(this.ControllerContext.RouteData.Values["action"] + "Partial");
            case FileFormat.Clean:
                if (viewName != string.Empty)
                {
                    return View(viewName, "~/Views/Shared/Clean.master", viewModel);
                }
                var v = View(viewModel);
                v.MasterName = "~/Views/Shared/Clean.Master";
                return v;
            default:
                throw new FormatException(string.Concat("Cannot server the content in the request format: ", RequestedFormat));
        }
    }
    protected ActionResult FormatView(object viewModel)
    {
        return FormatView("", viewModel);
    }




}

Clean.master - это просто главная страница, которая не содержит никаких дополнительных html - она ​​берет представление (так что я могу объединить любое частичное классы) и выводит его с чистым HTML, который может быть размещен непосредственно.

Если я хочу json - контроллер создает мою модель представления и затем возвращает эту модель представления как json вместо отправки в представление по умолчанию - то же самое с .xml.

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

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

1. Нет стандартного языка шаблонов для JavaScript. В худшем случае у вас возникнет соблазн объединить строки для формирования нужного HTML.
2. Нет простого способа модульного тестирования HTML, созданного вашим кодом объединения.
3. Отсутствие IntelliSense для вашего JavaScript означает, что вы также склонны делать больше ошибок.

Я поступил так, как будто возвращал отрисованный HTML, НО возвращал отрисованный HTML, используя вместо этого частичное представление. Это дает вам лучшее из обоих миров. У вас есть серверные шаблоны, а также поддержка IntelliSense.

Вот пример:

Вот мой вызов Ajax, Нет необходимости понимать это, я просто показываю вам, насколько сложным может быть рендеринг в реальном приложении. Я бы боялся делать это на JavaScript. Вы также заметите, что мое частичное представление, в свою очередь, вызывает и другие частичные представления.):

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl<IEnumerable<Request>>" %>
<%@ Import Namespace="Diangy.HelpDesk.Models.Lookups"%>
<%@ Import Namespace="Diangy.HelpDesk.Models.Requests"%>
<%@ Import Namespace="System.Web.Mvc.Html"%>

<% foreach (var request in ViewData.Model) %>
<%{%>
    <li class="request">
        <h2>#<%= request.Id %>: <%= request.InitialInteraction().Description %></h2>
        <p>from <%= request.Customer.FullName %> (<%= request.Customer.EmailAddress %>), <%= request.InitialInteraction().UsableTimeStamp %></p>

        <h3>Custom Fields & Lookups</h3>
        <div class="tabs">
            <ul>
            <li><a href="#customfields<%= request.Id %>">Custom Fields</a></li>
            <% foreach (var lookupDefinition in (List<LookupDefinition>)ViewData["LookupDefinitions"]) %>
            <%{%>
            <li><a href="#<%= lookupDefinition.Name.ToLowerInvariant().Replace(" ", "") + request.Id %>"><%= lookupDefinition.Name %></a></li>
            <%}%>
        </ul>
        <% Html.RenderPartial("CustomFields", request); %>
    </div>

    <% Html.RenderPartial("Discussion", request); %>
    <% Html.RenderPartial("Attachment", request); %>
    </li>
<%}%>

Для разделения проблем вы должны вернуть JSON.

Когда вы возвращаете html, вы ограничиваете то, что вы можете делать с возвращенными данными. Если вам нужен список данных и вы хотите представить его по-разному, используйте JSON, в противном случае вам понадобятся разные методы на сервере для получения разных визуализаций одних и тех же данных.

Why not both json and html? В текущем проекте мы создаем маршруты, чтобы вы могли выбирать из внешнего интерфейса, какой формат лучше всего подходит в некоторых случаях ... так почему бы не сделать два контроллера, сначала будут возвращены ожидаемые данные в json, а другой контроллер вернет то же самое data, но с html ... таким образом вы можете выбрать, скажем, jQuery, что и когда вы хотите и в каком формате вы хотите ... и лучше всего, для другого формата вам просто нужно вызвать другой адрес ...

другими словами, успокойся, детка! :)

ура

Что касается меня, я выбираю подход, основанный на данных. Вот небольшой набор функций для обоих:

Управляемый данными:

1. JSON с сервера (контроллер отправляет модель непосредственно в ответ)
2. Связывание шаблона JS (может занять больше времени на стороне клиента)
3. Низкий пропускная способность load
4. Это так сексуально!

Управляемый HTML:

1. HTML с сервера (Контроллер отправляет модель в какое-то частичное представление, он отображает результат и возвращает его - может потребоваться больше времени на стороне сервера)
2. Нет перегрузки в привязке JS
3. Высокая пропускная способность load
4. Не сексуально, нет, нет :)

Таким образом, вы можете поддерживать MVC даже с помощью подхода, основанного на HTML, хотя это будет немного сложнее.