Как мы использовали для разработки веб-приложений, когда Spring Framework не было?

Как мы используем для разработки веб-приложений, когда Spring Framework не было? Я начал с Spring MVC для разработки веб-приложений, но как мы разрабатывали веб-приложения, когда Spring не существовал?

Всего 1 ответ


Некоторые люди пишут все в JSP. Бизнес-логика добавляется обычно как серверная часть. Это было названо моделью 1 .

Несмотря на концептуальную простоту, эта архитектура не способствует крупномасштабной разработке приложений, поскольку неизбежно большое количество функциональных возможностей дублируется в каждой JSP. Кроме того, архитектура модели 1 излишне связывает воедино бизнес-логику и логику представления приложения.

Следующим уровнем сложности было использование сервлетов в качестве уровня контроллера. Это была модель 2 :

Модель 2 JSP - это сложный шаблон проектирования, используемый при разработке веб-приложений Java, который отделяет отображение содержимого от логики, используемой для получения и управления содержимым. Поскольку модель 2 определяет разделение между логикой и дисплеем, она обычно связана с парадигмой модель-представление-контроллер (MVC).

Затем появились веб-фреймворки, такие как Struts, так что у вас было что-то похожее на Spring web MVC, в котором был сервлет-диспетчер, который отправлял запросы контроллерам (действия Struts), за исключением того, что не было понятия DI. Жестко запрограммированные синглтоны, выполняющие бэкэнд-логику, были вызваны из действий распорок.

Ох, а затем был EJB. Были объекты EJB Home, которые были похожи на локаторы служб, и сессионные компоненты без сохранения состояния, которые были похожи на службы. Было много настроек, удаленное взаимодействие запекалось независимо от того, нужно вам это или нет, и тестирование было нелепо трудным, нам пришлось использовать Cactus, OpenEJB и XDoclet. И были сессионные bean-компоненты с состоянием, которые были ужасны, и Entity Beans, которые почти никто не мог понять, как заставить работать, и как только вы начали работать, стало ясно, что это плохая идея. Код EJB сделал невозможным тестирование без сервера приложений, и перенос приложений, использующих EJB, с одного сервера приложений на другой был затруднен.

Доступ к данным EJB был настолько болезненным, что люди вернулись к JDBC. Были также ORM, такие как Torque и Toplink. К концу этого периода Hibernate был создан, и это было большое улучшение, но было трудно получить работу.

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

Итак, в итоге, у вас был навязчивый инфраструктурный код, который не поддается проверке, и это была проблема, для решения которой был создан Spring.


Есть идеи?

10000