EJB 3.1 @LocalBean проти анотацій

Я розумію різницю між локальним видом, віддаленим видом та видом без інтерфейсу. Я просто не розумію, в чому різниця між "без перегляду" (без анотацій) та без інтерфейсу. А також чому я повинен коментувати свій інтерфейс @Local? Що робити, якщо я взагалі не анотую інтерфейс, чи є різниця?

Правила (з пам'яті):

1. Bean має @LocalBeanанотацію -> bean має вигляд без інтерфейсу
2. Bean має @Localанотацію -> bean має місцевий вид
3. Bean має @Remoteанотацію -> bean має віддалений вигляд
4. Bean не має анотацій подання, але безпосередньо реалізує інтерфейс, який має анотацію @Local -> bean має локальний вигляд
5. Bean не має анотацій подання, але безпосередньо реалізує інтерфейс, який має анотацію @Remote -> bean має віддалений вигляд
6. Bean не має анотацій подання, але безпосередньо реалізує інтерфейс, який не має анотацій подання -> bean має локальний вигляд
7. Bean не має анотацій подання та не реалізує інтерфейсів -> bean має подання без інтерфейсу

Отже, використання @LocalBeanта використання жодної анотації - це обидва способи отримання перегляду без інтерфейсу. Якщо ви просто хочете не переглядати інтерфейс, то найпростіше не коментувати. За умови, що ви також не реалізуєте жодних інтерфейсів.

Частина причини @LocalBeanіснує для додавання подання без інтерфейсу до компонента, який також має інтерфейс. Думаю, сценарієм, який був найвищим у свідомості авторів специфікацій, був такий, коли у вас є така квасоля:

@Stateless
public class UserPreferences {
    public String getPreference(String preferenceName);
    public Map<String, String> getPreferences();
}

Де ви хотіли б виставити обидва методи локально, але лише getPreferences()віддалено грубіше . Ви можете зробити це, оголосивши віддалений інтерфейс саме цим методом, а потім просто вдаривши @LocalBeanпо класу bean. Без нього вам довелося б писати безглуздий локальний інтерфейс, аби локально виставити обидва методи.

Або, якщо подивитися на це по-іншому, @LocalBeanіснує, оскільки існує таке поняття, як перегляд без інтерфейсу, а опція заборони анотацій існує як зручний ярлик.

• Віддалені EJB: можна отримати доступ із віддалених клієнтів (клієнти, що працюють на різній JVM, такі як клієнти Swing або JavaFX, які працюють на користувацькій машині)
• Локальні EJB: доступ може бути лише до інших "компонентів", що працюють на тій самій JVM, наприклад, до веб-інтерфейсів, інших EJB
• Вигляд без інтерфейсу: такий самий, як і в Local, але без зазначення ділового інтерфейсу
• Без анотацій: простий POJO, але не EJB

Місцеві перегляди / подання без інтерфейсу ефективніші, ніж віддалені EJB, оскільки посилання на об'єкти можна передавати.

Я думаю, що плутанина, яку ви / ми відчуваємо, є результатом історії / зворотної сумісності (так би мовити). Я не можу розрізнити жодної різниці (за винятком того, що специфікація вимагає реалізації для створення інтерфейсу, якщо ми використовуємо local-view)

Представлення без інтерфейсу має таку ж поведінку, як і локальний вигляд EJB 3.0, наприклад, воно підтримує такі функції, як семантика виклику прохідного посилання та розповсюдження транзакцій та безпеки. Однак подання без інтерфейсу не вимагає окремого інтерфейсу, тобто всі загальнодоступні методи класу bean автоматично піддаються виклику. За замовчуванням будь-який компонент сеансу, який має порожнє реалізаційне речення і не визначає жодних інших локальних або віддалених подань клієнта, виставляє неінтерфейсний перегляд клієнта.

Блог Oracle до випуску EJB 3.1

Якщо вас цікавлять додаткові технічні деталі, дозвольте мені сказати, що насправді відбувається .... Ви не маєте доступу до об’єкта EJB безпосередньо, це означає, що у вас немає посилання (адреси) фактичного об’єкта EJB. Коли ви шукаєте або вводите свій EJB, контейнер надає об'єкт як клієнт для цього EJB (ми можемо викликати проксі-сервер або Wrapper), і ви викликаєте свої бізнес-методи на цьому об'єкті-проксі. (Ось чому ви не повинні використовувати нове ключове слово для створення об’єкта класу EJB)

Тепер для кожного типу анотацій контейнер генерує різні типи проксі з різними методами та функціональними можливостями.

@LocalBean (або немає анотації) Ваш об’єкт проксі має:

• setOptionalLocalIntfProxy()
• getSerializableObjectFactory()

@Local Ви об'єкт-проксі використовуєте локальний виклик і тип com.sun.proxySo Так він має:

• getSerializableObjectFactory()
• isProxyClass()
• getProxyClass()
• getInvocationHandler()
• newProxyInstance()

@Remote Об’єкт Wrapper використовує віддалений виклик, і він має:

• readResolve()
• writeReplace()
• getStub()
• getBusinessInterfaceName()