Почему методы доступа из спецификации JavaBean стали стандартом для разработки Java?

JavaBeans Спецификация описывает как JavaBean

Java Bean - это программный компонент многократного использования, которым можно визуально манипулировать в инструменте разработчика

Поскольку большинство написанных строк кода не имеют ничего общего с визуальным манипулированием в инструменте компоновщика, почему спецификация JavaBean была «способом» написания объектно-ориентированного кода?

Я хотел бы отказаться от традиционного метода получения / установки в пользу Fluent Interfaces по всему коду, не только для разработчиков, но и боюсь делать это, так как это традиционно не способ, которым объектно-ориентированный код пишется в Java.

Средства доступа в стиле JavaBean хорошо зарекомендовали себя для всех видов сценариев, которые похожи на исходный сценарий «инструмента для разработчика» в одной ключевой точке: компоненты передаются и управляются общими контейнерами и инструментами, а также кодом приложения. На сервере приложений есть служебные компоненты, к которым контейнер EJB или Spring добавляет транзакции и внедрения зависимостей, модели постоянных доменов, к которым ORM добавляет ленивую загрузку и обнаружение изменений, и которые можно сериализовать в XML библиотекой без какого-либо специального кода.

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

В отличие от этого, текущие интерфейсы часто разрабатываются для однократного использования: создается объект, вызывается цепочка методов, которая заканчивается методом, дающим конечный результат, а затем объект забрасывается. Гораздо меньше гибкости (в основном это необязательные методы) и универсальности, но в этом и есть преимущество: интерфейс вынуждает вас использовать шаблон предполагаемого использования, что делает его очень простым в использовании.

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

Итак, поскольку спецификация JavaBeans, на которую вы ссылаетесь, определяет соглашение о доступе к свойствам, люди решили воспользоваться этим соглашением и создали вокруг него фреймворки. Некоторые из этих фреймворков, такие как Hibernate, были весьма полезны и стали очень популярными. Таким образом, поскольку люди использовали фреймворки, основанные на спецификации JavaBeans, javaBeans становился все более и более повсеместным, и вокруг них строилось все больше и больше фреймворков.

Свободные интерфейсы - отличная идея, но хорошо ли они работают со Spring или Struts 2? Бьет меня