2013-12-20 2 views
0

Я написал простой API поиска, используя MVC, который я могу запросить из JQuery. Сейчас мой код выглядит примерно так:MVC - доступ к модели представления с контроллера API

$.ajax({ 
     url: 'api/search', 
     type: "POST", 
     data: paramString, 
     dataType: "json", 
     success: function(data) { 
      $('#dataTable').append('<tr>' + '<td>' + params.SearchString + '</td>' + '<td>' + params.DateFrom + '</td>' + '<td>'+ params.DateTo + '</td>' + '<td>'+ JSON.stringify(data) + '</td>' + '</tr>'); 
     } 
    }); 

В основном все, что я делаю, это отправить критерии поиска в API, получить результаты обратно, а затем написать соответствующие критерии и результаты поиска в новую строку в результатах таблицу, непосредственно в HTML.

По понятным причинам мне не нравится это решение; он фактически не помещает данные в какую-либо структуру данных, а просто отбрасывает их в HTML, что затрудняет манипулирование ими в будущем и не выполняет хорошую работу по основным принципам проектирования MVC.

Я пытаюсь реорганизовать его так, что вызов API ничего не возвращает и добавляет результат поиска в список в ViewModel, который я могу отображать динамически.

Однако я не могу найти разумный способ получить модель контроллера API. Он хранится на стороне сервера, поэтому я не думаю, что мне нужно передать его через представление через javascript, но я не могу придумать лучший способ.

Спасибо!

+1

Я думаю, что вам лучше иметь свой обратный сервис JSON, а затем вывод, что в любом случае вам нравится в вашем представлении. – user1477388

+2

Вы не можете «добавить результат поиска к списку в модели просмотра», потому что после подачи ответа на ajax (и даже после загрузки страницы) модель представления больше не существует. –

ответ

1

Если вы используете API через ajax, мой подход состоял в том, чтобы вернуть json, а затем использовать шаблоны mustache, чтобы данные выглядели хорошо.

$.ajax({ 
    url: 'api/search', 
    type: "POST", 
    data: paramString, 
    dataType: "json", 
    success: function(data) { 
     var template = $('#searchTpl').html(); 
     var html = Mustache.to_html(template, data); 
     $('#dataTable').append('<tr><td>' + params.SearchString + '</td><td>' + params.DateFrom + '</td><td>'+ params.DateTo + '</td><td>'+ html + '</td></tr>'); 
    } 
}); 

И если ваш json будет выглядеть;

{ 
    results: [ 
    { 
     pageName : "Header of hit 1", 
     pageDescription: "Description of page", 
     searchHitUrl: "http://stackoverflow.com" 
    }, 
    { 
     pageName : "Header of hit 2", 
     pageDescription: "Description of page", 
     searchHitUrl: "http://imdb.com" 
    }] 
}; 

Шаблон определяется следующим образом в index.html:

<script id="searchTpl" type="text/template"> 
{{#results}} 
    <h3>{{pageName}}</h3> 
    <p>{{pageDescription}} <a href="{{searchHitUrl}}">{{searchHitUrl}}</a></p> 
{{/results}} 
</script> 
0

Что вы ищете, это MVC на стороне клиента, и именно поэтому я бросил ASP.NET MVC в пользу AngularJS + ASP.NET Web API. Я ненавидел возвращать HTML-фрагменты в ответ на запросы AJAX, но не имел простого способа привязать JSON без написания много беспорядочного, неструктурированного jQuery. Есть много других вариантов, таких как Backbone, KnockoutJS, Mustache.

+0

Вы находите, что это хорошо работает для широкомасштабных приложений? Я изучал все это в последнее время, но задаюсь вопросом, насколько они масштабируемы. Возможно, это не лучшее место, чтобы спросить ... – statue

+0

Ну, мы использовали его только для создания внутренних приложений, используемых сотнями (а не тысячами) пользователей. Вещи, которые мы традиционно реализовали бы как приложения для форм Windows, так что трудно говорить по опыту. Что касается серверной части, это просто вызовы API, поэтому все зависит от вашей реализации API: кэширования и т. Д. На клиенте Angular имеет дело с кэшированием шаблонов представлений, а также поддерживает легко кэширование других долговременных данных. Вы склонны просто видеть вызовы API, а не полные загрузки страниц, поэтому они очень отзывчивы. – natwallbank

+0

Мы видели нечетную проблему производительности на клиенте при связывании больших объемов данных, например. огромные списки, но, как правило, они могли создавать вокруг этого. В каждом новом выпуске есть улучшения производительности, некоторые планы в плане улучшения для дальнейшего развития. – natwallbank

Смежные вопросы