Какая гранулярность контроллера подходит в стиле MVC для большого веб-сайта? - PullRequest
0 голосов
/ 25 апреля 2011

Мы (моя команда и я) имеем большой веб-проект, который будет работать со многими пользователями (не менее 15 000 пользователей!).На этапе разработки мы решили написать код в стиле MVC.Мы сталкиваемся с компромиссом (в этом проекте все действия должны выполняться аутентифицированными пользователями).

Один из способов проектирования может быть следующим: контроллер получает запрос и в соответствии с ним создает (загружает из БД) ответственный объектдля запроса ссылка на этот объект сохраняется в контроллере и, наконец, контроллер добавляется в сеанс пользователя.Этот стиль требует, чтобы контроллер был грубым гранулированным классом с множественным поведением среди возможных действий пользователя, которые имеют высокую частоту.

Другой способ проектирования может быть следующим: контроллер получает запрос, затем создает ответственный объект для запроса, ноэтот контроллер не имеет состояния и имеет специфическое поведение, например, в соответствии с одной страницей веб-сайта.Таким образом, для каждой страницы мы должны создать контроллер, и, если ему нужна информация, распространенная на некоторых страницах, мы должны загрузить их из БД или из ее кэша.

  • В первом стиле контроллер должен быть грубымгранулированный объект из-за уменьшения количества созданий и сборщиков мусора, поэтому он создается только один раз после аутентификации пользователя и не будет мусором до истечения срока действия сессии.Жизненный цикл объектов, которые существуют в сеансе, продолжается до истечения сеанса, поэтому я думаю, что это может быть причиной нехватки памяти!
  • Во втором стиле для каждого перехода пользователя на другую страницу должен быть создан один контроллер, который извлекает информацию изБД, может быть причиной проблем с производительностью!

Мой запрос: я хочу сравнить их с двумя аспектами, использованием памяти и производительностью!И если есть какие-либо предложения, я буду рад их упомянуть!

Простой пример приведен на следующем рисунке:

http://v1.iimmgg.com/images/is7gr/fb0f6b763eea5294815dcb2d50a12f56.png

Ответы [ 3 ]

0 голосов
/ 25 апреля 2011

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

0 голосов
/ 26 апреля 2011

Мое эмпирическое правило - следовать принципам REST

Каждый бизнес-объект является ресурсом.Ресурсы должны иметь контроллеры.

Значимые объекты, такие как электронная почта, деньги и т. Д., Не являются ресурсами.

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

0 голосов
/ 25 апреля 2011

Фактическое разделение сайта на многие контроллеры не будет иметь значения с точки зрения доступа к БД, поскольку объект поддерживается на протяжении всего сеанса. Разделение сайта на множество контроллеров не означает, что вы разделяете сеанс.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...