dependency injection - EJB3 vs Data Access Objects -

i working on project need decide how going expose our persistence layer.

there 2 options on table:

1) use plain daos. these implement interface , injected (probably using weld) in business components ejbs. internally use jpa/hibernate persistence.

2) rather injecting daos using weld, implemented ejbs, , injected @ejb in business components.

does make sense use ejbs persistence layer when not using capabilities (e.g. transaction management - business layer deals this)?

is there performance penalty in using ejb on weld (or other way round)?

what option think best?

using ejbs jpa based dao natural fit.

if transaction starts in business layer (which ejbs mention) transaction naturally propagate them. should ever want use dao separately, transaction started you. may not use feature now, comes totally free should ever need it.

also, should ever need single operation in own transaction, trivial when daos ejb based.

injecting business ejbs dao ejbs may have potential performance advantage. stubs injected delegate pooled instances, injection relatively cheap. can inject business ejbs many daos may or may not necessary every call. i'm not 100% sure cdi has exact same capability. of course has scoping , conversations not stubs delegate pool.

should ever need jpa's extended persistence context, stateful session bean practically made that, otherwise stateless session bean used daos.

that said, cdi more modern component model , current thinking seems ejb retrofitted set of cdi annotations. starting build cdi codebase , knowledge may long term strategic benefit, , bodes cdi.

so answer question more directly: yes makes sense use ejbs persistence layer, neither ejb or cdi absolutely wrong choice here.