Сервлеты и рамки MVC

Ответ 1

Я расскажу некоторые из своих мыслей об этом.

• Как было сказано выше, эти структуры разрабатываются поверх Servlet/JSP.
• Они предназначены для предотвращения дублирования кода (DRY). Структура
• основана на Design Patterns - общем многоразовом решении для часто встречающихся проблем.
• Они помогают легко передавать вещи в команде и делают их продуктивными и сосредоточенными на проблеме уровня предприятия, которую они пытаются решить, чем эти общие задачи.
• Они помогают ускорить разработку, предоставив общее решение для общеизвестных проблем. (например, проверка формы, REST, тестирование, зависимость и т.д.).

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

Я считаю, что это правило применяется не только для servlet-jsp, но и для JavaScript. Простого JavaScript-кода JavaScript или даже низкого уровня JavaScript API/Библиотеки недостаточно при создании пользовательского интерфейса корпоративного масштаба. Либо принять Лучшую доступную структуру, либо абстрагироваться от общего характера и сделать ее основой (а не библиотекой).

Ответ 2

Spring MVC по-прежнему работает с JSP, и в его основе он предоставляет не что иное, как простой сервлет диспетчера, который использует механизмы, предоставляемые инфраструктурой MVC Spring (где вы регистрируете свои контроллеры и т.д.). Я бы сказал, что речь идет об удобстве и упрощении написания и обслуживания. Кроме того, вы можете более легко реагировать на текущие события (например, RESTful services... вам нужно будет все это закодировать вручную в сервлете). В конце концов, для чего нужны рамки.