#c# #asp.net #tsql
#c# #asp.net #tsql
Вопрос:
Я собираюсь написать множество внутренних методов C # для моей веб-страницы, чтобы обновлять данные в базе данных из 17 элементов управления на самой моей странице.
Непосредственно перед тем, как я напишу 17 методов для обработки процедуры обновления моей базы данных, я хотел бы знать, было бы эффективнее написать 1 огромный метод для обработки всех моих сценариев обновления для всех элементов управления моей веб-страницы? Я собираюсь использовать объект SqlConnection вместе с SqlCommand для достижения этой цели.
Что я пытаюсь предотвратить, так это длительные запросы на моей веб-странице из-за слишком большого количества методов (если это вообще возможно)
По умолчанию, если мои элементы управления оставлены пустыми, никакие соответствующие данные (например, название карьеры) в моей таблице в базе данных не должны изменяться.
Итак, было бы лучше написать 17 различных методов для моих 17 элементов управления? или написать 1 большой метод проверки для поиска по содержимому каждого элемента управления и последующего запуска сценария обновления?
Небольшое уточнение
Эти 17 методов, которые я хотел написать для каждого элемента управления, будут вызываться только в том случае, если соответствующий элемент управления не имеет значения по умолчанию (поэтому, если текстовое поле 5 пустое, то метод обновления текстового поля 5 не будет вызываться).
Комментарии:
1. Трудно сказать, не зная природы данных и вероятного количества требуемых запросов (в среднем). Что я могу сказать, так это то, что 17 циклов обращения к базе данных будут намного медленнее, чем один.
2. Я вижу, что мой вопрос был немного двусмысленным. Я немного прояснил
Ответ №1:
Вероятно, стоит убедиться, что это всего лишь один вызов базы данных, но будет ли это один метод или 17, не будет иметь никакого существенного значения вообще, если два подхода фактически выполняют одно и то же. Разница может быть незначительной, но время, потраченное на общение с базой данных, затмит все остальное.
Комментарии:
1. Черт возьми — я получил тот же ответ добрых 30 секунд назад; но кто-то остановился у моего стола и задал вопрос — снова сорвано!
2. @Eon: Ничто не должно мешать вам использовать этот метод — просто не выполняйте вызов сервера более одного раза.
3. @Eon: Нет, нет, нет. Разделите метод на несколько методов — один «координирующий» метод, который вызывает остальные. Таким образом, вы сможете протестировать их независимо, и это будет проще для понимания.
4. @Eon: Тогда я не понимаю, почему вы хотите поместить все в один гигантский метод… или почему вы думаете, что это было то, что я предлагал.
5. @Eon: Я не вижу абсолютно никакой причины использовать здесь делегат. Просто разделите метод, используйте один метод, который мало что делает, но вызывает другие, собирает результаты и вызывает базу данных.
Ответ №2:
Было бы лучше выполнить только один запрос на обновление к серверу sql. Накладные расходы на связь с sql server будут самой медленной частью обновления, если вы сделаете один вызов хранимой процедуры на сервере, это будет в 17 раз быстрее, чем 17 вызовов на сервер.
Ответ №3:
Накладные расходы на базу данных намного превысят незначительные накладные расходы на вызов метода.
В общем, пока у вас нет доказательств того, что вам это нужно, не жертвуйте поддерживаемым кодом ради производительности.
Обратите внимание, что это при условии, что рабочий процесс базы данных одинаков для обоих вариантов! Выполнение 17 вызовов к базе данных вместо одного абсолютно заметно снизит производительность.
Комментарии:
1. итак, 1 большой метод для проверки всех моих элементов управления, а затем создание окончательного сценария для обновления таблицы в моей базе данных — лучший ход тогда?