Шаблон репозитория - витрина MVC
Вы можете попробовать SpreadsheetApp.flush ().
function addSong() {
var ss = SpreadsheetApp.getActive();
var sheet = ss.getActiveSheet();
var lastRow = sheet.getLastRow()
sheet.appendRow([lastRow+1]);
SpreadsheetApp.flush();
var range = sheet.getRange(sheet.getLastRow(), 1);
SpreadsheetApp.setActiveRange(range);
}
Это должно сбросить электронную таблицу и сделать изменения правильными, а не ждать, пока скрипт завершит добавление этой последней строки.
3 ответа
Аргументы могут быть приведены так или иначе, видеть это недавнее сообщение в блоге: мой репозиторий должен выставить IQueryable?
Проблема, которую я имею с представлением IQueryable к Уровню служб, - то, что, если Вы когда-нибудь хотели перенести уровень Repository позади веб-сервиса, не взламывая код Уровня служб, Вы не могли, хорошо, не используя Услуги передачи данных ADO.NET, но затем весь Ваш код Репозитория по существу станет избыточным.
Пока я думаю, что это может быть довольно продуктивно для небольших приложений, когда Вы начинаете смотреть на масштабирование и распределение, это делает более плохой, чем хороший.
Материал IQueryable тот Rob Conery, помещенный в Витрину MVC, инновационен, но ни в коем случае норма когда дело доходит до создания репозиториев. Обычно, репозиторий ответственен за отображение Вашего домена к и от базы данных. Возврат IQueryable действительно не выполняет отображения и полагается на сервисный слой, чтобы сделать это. Это имеет его преимущества и недостатки, но достаточно сказать, что это не единственный способ сделать это.
Вы заметите, однако, что Ваши сервисы заканчивают тем, что стали немного вонючими из-за всего дублирующего кода. Например, если бы Вы просто хотите получить список всех пользователей в Вашей базе данных, необходимо было бы определить ту функцию и в репозитории и в уровне служб. То, где уровень служб сияет, однако, когда несколько транзакций к/от базе данных необходимы для одной операции.