Enterprise Intermedio

Sostituisci i fragili lookup JNDI basati su stringhe con l'iniezione CDI type-safe per le risorse gestite dal container.

✕ Java EE
public class OrderService {
    private DataSource ds;

    public void init() throws NamingException {
        InitialContext ctx = new InitialContext();
        ds = (DataSource) ctx.lookup(
            "java:comp/env/jdbc/OrderDB");
    }

    public List<Order> findAll()
            throws SQLException {
        try (Connection con = ds.getConnection()) {
            // query orders
        }
    }
}
✓ Jakarta EE 8+
@ApplicationScoped
public class OrderService {
    @Inject
    @Resource(name = "jdbc/OrderDB")
    DataSource ds;

    public List<Order> findAll()
            throws SQLException {
        try (Connection con = ds.getConnection()) {
            // query orders
        }
    }
}
Vedi un problema con questo codice? Faccelo sapere.
🔒

Wiring type-safe

Gli errori di iniezione vengono rilevati al momento del deploy, non a runtime tramite lookup di stringhe.

🗑️

Nessun boilerplate

Elimina la creazione di InitialContext, le stringhe JNDI e la gestione di NamingException.

🧪

Testabile

Le dipendenze sono campi iniettati, facilmente sostituibili con mock nei test unitari.

Approccio Vecchio
Lookup JNDI
Approccio Moderno
CDI @Inject
Dal JDK
11
Difficoltà
Intermedio
Lookup JNDI vs Iniezione CDI
Disponibile

Ampiamente disponibile da Jakarta EE 8 / Java 11

Il pattern JNDI tradizionale ti costringe a usare nomi di risorse basati su stringhe, gestire NamingException e gestire un InitialContext. L'iniezione CDI con @Inject (o @Resource per le risorse container) lascia che il container crei automaticamente le dipendenze. I typo diventano errori di compilazione, e le classi sono più facili da testare perché le dipendenze possono essere iniettate direttamente.

Condividi 𝕏 🦋 in