Какая гранулярность контроллера подходит в стиле MVC для большого веб-сайта?
У нас (моей команды и меня) есть большой веб-проект, который будет работать со многими пользователями (не менее 15 000 пользователей!). На этапе разработки мы решили написать код в стиле MVC. Мы сталкиваемся с компромиссом (в этом проекте все действия должны выполняться аутентифицированными пользователями).
Одним из способов проектирования может быть: контроллер получает запрос и в соответствии с ним создает (загружает из БД) ответственный объект для запроса, затем ссылка на этот объект сохраняется в контроллере и, наконец, контроллер добавляется в сеанс пользователь. Этот стиль требует, чтобы контроллер был грубым гранулированным классом с множественным поведением среди возможных действий пользователя, которые имеют высокую частоту.
Другой способ проектирования может быть следующим: контроллер получает запрос, затем создает ответственный объект для запроса, но этот контроллер не имеет состояния и имеет специфическое поведение, например, в соответствии с одной страницей веб-сайта. Таким образом, для каждой страницы мы должны создать контроллер и, если ему нужна информация, распространенная на некоторых страницах, мы должны загрузить их из БД или из ее кэша.
- В первом стиле контроллер должен быть грубым гранулированным объектом из-за уменьшения объема создания и сбора мусора, поэтому он создается только один раз после аутентификации пользователя и не будет мусором до истечения срока действия сеанса. Жизненный цикл объектов, которые существуют в сеансе, до истечения сеанса, поэтому я думаю, что это может быть причиной нехватки памяти!
- Во втором стиле для каждого перехода пользователя на другую страницу должен быть создан один контроллер, который извлекает информацию из БД, может быть причиной проблем с производительностью!
Моя просьба: я хочу сравнить их с двумя аспектами, использованием памяти и производительностью! И если есть какие-либо предложения, я буду рад их упомянуть!
Для простого примера, смотрите рисунок ниже:
http://v1.iimmgg.com/images/is7gr/fb0f6b763eea5294815dcb2d50a12f56.png
3 ответа
Мое эмпирическое правило - следовать принципам REST
Каждый хозяйствующий субъект - это ресурс. Ресурсы должны иметь контроллеры.
Ценные объекты, такие как электронная почта, деньги и т. Д., Не являются ресурсами.
В некоторых случаях контроллеры следует объединять, когда простота перевесит сложность, добавит дополнительный контроллер, и сущности будут напрямую связаны.
В большинстве случаев уровень доступа к данным определяет производительность системы при минимальном влиянии размера контроллера в приложении mvc. с точки зрения дизайна, я бы посоветовал вам хранить логически связанные действия в одном контроллере, чтобы у вас было много маленьких контроллеров. с точки зрения производительности вы должны сосредоточиться на своем доступе к БД и найти оптимизацию, к которой он относится.
Фактическое разделение сайта на многие контроллеры не будет иметь никакого значения с точки зрения доступа к БД, поскольку объект поддерживается на протяжении всего сеанса. Разделение сайта на множество контроллеров не означает, что вы разделяете сеанс.