Entity beans er ikke dårlige. De er designet til et specifikt formål.
Sammenligning:
En HashMap er god til at slå op på key. Dårlig til at finde element nummer 741. Den er ikke "god" eller "dårlig" - den er designet til et bestemt formål. Og til et andet formål vælger man en anden type f.eks. ArrayList.
P.s. Grunden til at vi henter så mange rækker er at vores applikation skal præsenterer så mange lydfiler for brugeren. Han skal arbejde med dem og tilføje dem til en playliste.
Jeg har tilføjet det du skrev til log4j.xml konfiguration filen. Hvor kommer debug outputtet henne? Jeg har tjekket filerne i log mappen og outputvinduet. Der er ikke noget?
Den har registreret ændringen i konfigurationsfilen.
Jeg kommer til at udfordre dig på '1) Det passer altid med BMP.'!?
En standard finder 'findByZipCode(..)' ville nok implementeres som en 'SELECT * FROM ... WHERE ZIP_CODE = ?' så der er altså tale om en enkelt forespørgsel!
Jeg er enig i at det er ringe udnyttelse af containerens ressourcer - primært memory - at returnere 1000 entiteter. Men at der ligefrem bliver udført 1001 forespørgsler for at hente dem køber jeg ikke!!
Sådan kunne man have valgt at lave BMP entity beans, men det har man ikke.
En BMP entity bean finder returnerer en collection af primary keys, hvorefter containeren loader de enkelte beans ind i en ny collection.
1 * SELECT pkfelt FROM tabel WHERE andetfelt = ? N * SELECT * FROM tabel WHERE pkfelt = ?
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
