#asp.net-mvc #design-patterns #granularity
#asp.net-mvc #шаблоны проектирования #степень детализации
Вопрос:
У нас (моей команды и меня) есть большой веб-проект, который будет иметь дело со многими пользователями (не менее 15 000 пользователей!). На этапе разработки мы решили кодировать в стиле MVC. Мы сталкиваемся с компромиссом (в этом проекте все действия должны выполняться аутентифицированными пользователями).
Одним из способов проектирования может быть: контроллер получает запрос и в соответствии с ним создает (загружает из БД) объект, отвечающий за запрос, затем ссылка на этот объект сохраняется в контроллере и, наконец, контроллер добавляется в сеанс пользователя. Для этого стиля контроллер должен быть грубо детализированным классом с множеством вариантов поведения среди возможных действий пользователя, которые имеют высокую частоту.
Другим способом проектирования может быть: контроллер получает запрос, затем создает ответственный объект для запроса, но этот контроллер не имеет состояния и имеет определенное поведение в соответствии, например, с одной страницей веб-сайта. Таким образом, для каждой страницы мы должны создать контроллер, и если ему нужна информация, которая часто встречается на некоторых страницах, мы должны загрузить их из базы данных или кэша.
- В первом стиле контроллер должен быть грубо детализированным объектом из-за уменьшения создания и сборки мусора, поэтому он создается только один раз после аутентификации пользователя и не будет мусором до истечения срока действия сеанса. Жизненный цикл объектов, которые существуют в сеансе, длится до истечения срока действия сеанса, поэтому я думаю, что это может быть причиной нехватки памяти!
- Во втором стиле для каждого перехода пользователя на другую страницу должен быть создан один контроллер, который извлекает информацию из базы данных, что может вызвать проблемы с производительностью!
Моя просьба: Я хочу сравнить их с двумя аспектами, использованием памяти и производительностью! И если есть какие-либо предложения, я буду очень рад упомянуть об этом!
Простой пример, пожалуйста, смотрите на рисунке ниже:
http://v1.iimmgg.com/images/is7gr/fb0f6b763eea5294815dcb2d50a12f56.png
Комментарии:
1. Возможно, я чего-то здесь не понимаю, но зачем вам хранить контроллер в сеансе?
2. @KTF: Я могу хранить объект Entity вместо контроллера со ссылкой на него, но я думаю, что контроллер не является большим объектом (он почти не имеет состояния), поэтому при сохранении его в сеансе его создание и уничтожение может быть сокращено!
3. Вы выполняете много операций ввода-вывода данных или что-то интенсивное в методах построения / завершения контроллера? В противном случае фактическое создание / уничтожение самого класса требует очень небольших накладных расходов. Все еще не уверен, зачем вам хранить контроллер в сеансе. (Я предполагаю, что вы используете метод MVC?)
Ответ №1:
Мое эмпирическое правило — следовать принципам REST
Каждый бизнес-объект является ресурсом. Ресурсы должны иметь контроллеры.
Объекты ценности, такие как электронная почта, деньги и т.д., Не являются ресурсами.
В некоторых случаях контроллеры следует объединить, когда простота перевешивает сложность, добавился бы дополнительный контроллер, и объекты напрямую связаны.
Ответ №2:
На самом деле разделение сайта на множество контроллеров не будет иметь значения с точки зрения доступа к БД, поскольку объект поддерживается на протяжении всего сеанса. Разделение сайта на множество контроллеров не означает, что вы разделяете сеанс.
Ответ №3:
В большинстве случаев ваш уровень доступа к данным определяет производительность системы с небольшим влиянием размера контроллера в приложении mvc. с точки зрения дизайна, я бы посоветовал вам сохранить логически связанные действия в одном контроллере, чтобы у вас могло быть много маленьких контроллеров. с точки зрения производительности вы должны сосредоточиться на доступе к вашей базе данных и найти оптимизацию, к которой она относится.