Это плохая практика, чтобы "углубиться" с вашим применением обратных вызовов?

Question

Странный вопрос, но я не уверен, что это анти-паттерн или нет.

Скажем, у меня есть веб-приложение, которое будет рендерить 1000 записей в HTML-таблицу.

Типичный подход, который я видел, - это отправить запрос в базу данных, каким-то образом перевести записи в какое-то абстрактное состояние (будь то массив, или объект и т. Д.) И поместить переведенные записи в коллекцию. это затем повторяется в представлении.

По мере роста количества записей этот подход занимает все больше и больше памяти.

Почему бы не отправить вместе с запросом обратный вызов, который выполняет операцию с каждой из переведенных строк, когда они считываются из базы данных? Это означает, что вам не нужно собирать данные для дальнейшей итерации в представлении, поэтому объем памяти сокращается, и вы не выполняете итерации по данным дважды.

Должно быть, в этом подходе что-то явно не так, потому что я редко вижу, чтобы он использовался где-либо. Что не так с этим подходом?

Спасибо.

Answer 1

На самом деле, именно так должно вести себя хорошо разработанное приложение.

В этом подходе нет ничего плохого, за исключением того, что не все интерфейсы баз данных позволяют легко это сделать.

Если мы говорим о табулировании 10 записей для еще одной социальной сети, нет необходимости связываться с обратными вызовами, если вы можете получить массив хэшей или что-то еще с помощью одного вызова, который уже реализован для вас. *

Answer 2

Это класс проблем "ограничен вашими инструментами": большинство языков программирования не позволяют говорить "Делайте что-нибудь вокруг этого кода". Это было решено в последние годы с появлением закрытий. Думайте о замыкании как о способе передачи кода в другой метод, который затем выполняется в контексте. Например, в GSQL вы можете написать:

def l = []
sql.execute ("select id from table where time > ?", time) { row ->
    l << row[0]
}

Это откроет соединение с базой данных, создаст оператор и набор результатов, а затем запустит l << it[0] для каждой строки, которую возвращает БД. Обратите внимание, что код выполняется внутри sql.execute(), но он может обращаться к локальным переменным (l) и переменным, определенным в sql.execute() (row).

С помощью этого вида кода вы можете даже генерировать результат HTTP-запроса на лету, не сохраняя большую часть страницы в оперативной памяти в любое время. В моем случае я бы направил 2-мегабайтный документ в браузер, используя только несколько килобайт оперативной памяти, а затем браузер проглотил бы 83 секунды, чтобы проанализировать это.

Answer 3

Должно быть что-то неявно не так с этим подходом, потому что я редко вижу его где-либо используемым.

Я использую это. Часто. Даже если бы я не использовал слишком много памяти, многократно копируя данные, использование обратного вызова просто кажется чище. В языках с замыканиями он также позволяет хранить соответствующий код вместе, исключая беспорядочную работу с БД.

Answer 4

Я нашел, что проще использовать интерфейсный преобразователь, чем глубокий обратный вызов, где он подключен через несколько классов. У MS гораздо более причудливая версия, чем у меня, под названием Unity. Это обеспечивает более чистый способ доступа к классам, которые не должны быть тесно связаны

http://www.codeplex.com/unity

Answer 5

Это примерно то, что позволяет вам использовать шаблон итератора. Во многих случаях это нарушает интерфейс между вашим приложением и базой данных. Такие технологии, как LINQ, даже имеют решения, которые могут отправлять код обратно в базу данных.