Лучшая практика: загрузка представленного HTML или json?
Это должно работать, если блок не , тень скопировала :
string path = System.Reflection.Assembly.GetExecutingAssembly().Location
6 ответов
Пара вещей.
Во-первых, когда вы делаете такие вещи, как TDD, чтобы сделать ваш код тестируемым, вы получаете меньший класс. Если у вас есть класс с множеством частных свойств, которые вы не можете проверить, есть большая вероятность, что его можно разбить на несколько классов и сделать более тестируемым.
Во-вторых, ОО-архитектура старой школы пытается сделать программное обеспечение безопасным, используя языковые средства защиты для предотвращать доступ к вещам. Архитектура TDD делает программное обеспечение более надежным за счет написания тестов, которые проверяют, что код действительно делает, уделяя меньше внимания использованию языковых конструкций, чтобы убедиться, что программа не делает.
Наконец, проверка свойства - не единственный способ проверки код сделал то, что должен был делать. В книге «Шаблоны проектирования xUnit» описаны другие подходы здесь: http: // xunitpatterns.
Я бы пошел с # 1 ... так что вы действительно получаете данные, а не просто какой-то HTML ... это будет просто краткая структура объекта JavaScript, а не какая-то строка, поэтому вы можете оценивать данные по своему желанию, кэшировать их, использовать для поиска и т. Д. ... чем больше работы выполняется на стороне клиента и чем она умнее, тем лучше масштабируется ваше приложение ... у вас есть 1 сервер, а может быть 2-10, или я не знаю, но у вас их 10 -10000 других клиентов ...
greetz
back2dos
Я бы лично использовал метод №2. Зачем тратить время на синтаксический анализ на стороне клиента, который можно было бы легко и лучше выполнить с помощью серверного языка? Вместо того, чтобы создавать массив и затем преобразовывать его в json, было бы гораздо лучше просто просмотреть результаты и отобразить HTML.
Я бы проверил его в нескольких браузерах, но подозреваю, что №1 (передача в формате JSON) может оказаться быстрее. С помощью этого метода вы можете просто заменить значения для существующих узлов DOM. Например (очень упрощенное) изменение (непосредственно с использованием манипуляции с DOM):
<li>foo</li>
<li>bar</li>
<li>baz</li>
на:
<li>foo2</li>
<li>bar2</li>
<li>baz2</li>
, когда вы получаете JSON:
["foo2", "bar2", "baz2"]
Таким образом, вы не создаете новые узлы DOM без необходимости. Еще одно преимущество - JSON API будет более «аппетитным», если вы позже решите сделать его общедоступным в той или иной форме.
В большинстве случаев я говорю №1. Если вы хотите добавить кнопку страницы «следующая / предыдущая» за пределами обновляемого div, вы можете использовать JS, чтобы определить, когда их включать / отключать. Использование №1 дает вам гораздо больше гибкости и дополнительно отделяет данные от представления.
На мой взгляд, производительность и «простота разработки» незначительны. Производительность больше не очень велика для небольших «фрагментов» данных (при условии, что ваш JS находится в сфере здравомыслия), а «простота разработки» не является важным фактором, учитывая, что это легче поддерживать.
ну, кроме небольших накладных расходов на форматирование, загружаемое с сервера, которое может немного замедлить работу для большого количества данных, я не вижу никаких недостатков. И поскольку рендеринг javascript, вероятно, тоже будет медленным, я бы выбрал №2.