Сравнение JSP Scriptlet с MVC в отношении производительности

Question

Я пришел из интервью, и технический директор (технический директор) сказал мне, что есть система (которая работает более 5 лет), и они по-прежнему предпочитают не использовать MVC исключительно из-за производительности. Я знаю, что большинство MVC использует рефлексию для вызова методов (что, по сути, медленно), но многие MVC (я знаю, что Struts делает это, я читаю код) кэшируют методы, которые он вызывает, поэтому мне не нужно «находить» метод для вызывать все время.

Пока что они придерживаются скриптлетов (и не используют JSPTags). Интересно, есть ли огромная производительность чисто скриптов, чем MVC? Они предпочитают сеансы без сохранения состояния, а не сеансы с сохранением состояния, чтобы избежать миграции сеанса, отслеживания сеанса и т. Д.

Если то, что говорит технический директор, является правдой, то почему MVC по-прежнему предпочтительнее (я знаю, почему MVC существует, но с точки зрения производительности).

Answer 1

Противоположные аргументы:

• Отражение уже не , что медленнее с хороших двух лет
• Производительность оборудования безумно возросла за последние пару лет.
• MVC, наконец, приводит к ускорению разработки.Меньше потраченного времени = больше экономит $$$.

Я бы сдал работу.

Answer 2

Это довольно странная логика от CTO;Я не думаю, что он знает, о чем говорит (подсказка: передайте работу!) Если он так обеспокоен эффективностью, почему бы не переписать весь веб-приложение на языке ассемблера?

Аргументы против скриплетов

• Мне не нравятся скриптлеты, потому что их сложно поддерживать.Они также подвержены злоупотреблениям.Самое важное также то, что они смешивают логику представления с бизнес-логикой или, по крайней мере, делают ее чрезвычайно простой и заманчивой, чтобы сделать то же самое.

• Вы может разумно отделить ваши проблемы и использовать услуги, которые извлекают данные (и таким образом способствуют повторному использованию).Но чаще всего я видел, как разработчики пишут JSP как PHP-код (т. Е. Код, смешанный с разметкой).

Я не говорю, что вы не можете написать хороший код с JSP.Просто сложнее (мне кажется, у MVC больше защитных мер), а также (мне кажется) JSP более подвержены злоупотреблениям.

Аргументы для MCV

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

• Слой вида связан исключительно с визуализацией вида.Вы получаете метаданные от вашего контроллера и отображаете данные, используя представление.Вы не беспокоитесь о бизнес-логике здесь (и не должны быть).

• Контроллер действует как гаишник, перенаправляя ваши запросы по назначению.Контроллеры обычно заканчивают вызовом сервисов, которые выполняют всю бизнес-логику.

• Модель отвечает за данные и поведение области приложения.Модель будет отвечать на запросы о своем состоянии (так что это метаданные, которые вы отправляете в представление), а также будет отвечать на инструкции, которые сообщают ей об изменении состояния (от контроллера).

• Отражение на самом деле не так медленно.Кроме того, в наши дни компьютеры работают довольно быстро и имеют много памяти.Производительность не так уж и важна.

• Шаблон MVC обеспечивает четкое разделение между различными задачами, что позволяет разработчику легко писать чистый, надежный и поддерживаемый код.

Answer 3

Преимущества MVC перед скриптлетами прекрасно описаны в других ответах, но один момент упущен.

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