Thanks very much for your explanation. We are not too much concerned with
scalability as we do intranet apps, but they in fact deal mostly with set
operations as you say.
As you put it, it seems that I should stick with DAO (either JPA based or
not), and/or perhaps any other layer that makes DAO layer's life easier.
It's just that I feel the need of something below my DAO layer that help
and I thought JPA would fit well there.
Thanks again !!
Daniel
Hi,
> whatever is more complex than simple POJO CRUD, I do it with proper SQL in
> stored procedures. I like
> JPA a bit more than other ORM, but I still see it lacking in this regard.
JPA is more akin to Model-View-Controller (MVC) programming model where
Model = database record/schema
View = POJO/domain objects
Controller = JPA API/Session Beans
Such MVC perspective does not lend itself well with the notion of operating
directly on the model (i.e. database records) with SQL and stored procedures.
The advantage of operating on the view rather than the model is, by now,
well-established especially from scalability and flexibility (e.g. against
pre-existing database schema) standpoint.
Of course, stored procedure or hand-written SQLs that expose/bind an
application to the database schema are required for certain class of
applications (especially where set-based computation is predominant pattern
than navigational access or short-lived transaction). But that class of
application perhaps not the main focus or suitable for JPA-based applications.
Regards --
--
View this message in context:
http://n2.nabble.com/Looking-for-advice-on-JPA-based-DAO-tp2641707p2643410.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
