Справочный код сервисной стороны из тега <script>

Question

Я не знаю, откуда у меня появилась идея, но год назад я написал это в php:

<script type="text/javascript" src="http://www.mydomain.com/getmarkers.php"></script> 

Теперь я готов преобразовать этот веб-сайт в веб-сайт ASP.NET MVC, и мне интересно, как лучше всего превратить это в нечто более «нормальное»?

Варианты, о которых я мог подумать:

1. Пользовательский HttpHandler для файлов .js
2. Продолжайте использовать тег script, но с собственным маршрутом к действию
3. Изменить javascript для загрузки данных на стороне сервера с помощью вызова ajax

В настоящее время getmarkers.php создает javascript для добавления маркеров на карту Google. Преимущество ссылки на php внутри тега script заключается в том, что

1. Он никогда не кэшируется, маркеры всегда актуальны (я знаю, что есть альтернативы)
2. Он хранит мой html подальше от любого javascript
3. Очень легко добавлять / удалять определенные поля для сгенерированных маркеров

Пример того, что генерируется:

infoWindows[0] = new google.maps.InfoWindow({
    content: '<div style="width:250px;color:#000;">...html content for this specific marker...</div>'
});

google.maps.event.addListener(markers[0], 'click', function() {
    infoWindows[0].open(map, markers[0]);
});

Что меняет индекс (0 в этом примере) и содержание HTML.

Вопрос
1. Какое решение, по вашему мнению, подходит лучше всего
2. Плохо ли ссылаться на скрипт, вызывая серверный «файл».

Answer 1

Я не вижу никаких недостатков встраивания сгенерированных сервером файлов .js. Лично я бы выбрал опцию «пользовательский маршрут», чтобы было понятно, что это сгенерированный файл, а расширение .js остается для статических ресурсов.

Однако, обслуживание маркеров в чистом формате данных, таких как JSON, и загрузка их с помощью Ajax будет иметь преимущества, которые

• у вас есть данные в нейтральном «метаформате», которые вы можете использовать в другом месте без необходимости создания нового источника данных

• вы можете хранить процесс загрузки / генерирования HTML в одном месте, на родительской странице или в одном из его статических сценариев, вместо того, чтобы контролировать то, как HTML выглядит в сценарии на стороне сервера

• количество передаваемых данных, вероятно, уменьшено

• Чистее в целом