openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Toffetti <dto...@yahoo.com.ar>
Subject Re: Looking for advice on JPA based DAO
Date Fri, 17 Apr 2009 16:23:58 GMT

Hi Daryl,

    Yes if you are properly layering your application, your business logic should be clearly
separated and independent from your data storage layer. But as you've found, that's not always
that simple.
    Some people like to do things "the old way" and implement a lot of business logic in stored
procedures. I'm not going to argue in favor of this pretending it's better, it's simple the
way I prefer and that better fits our needs and out team.
    In my example below, SalesReportLineDAO calls a fairly complex sp that joins many tables,
groups, etc. and returns a collection of rows, that I want to treat as detached pojos and
data model for my Wicket application even when they are not backed by any table in the database.
    I simply define SalesReportLine as a pojo with the expected result columns from the stored
proc. I've even developed a small utility that introspect the database and writes pojos for
entities and even for the expected resultsets of every stored proc.
    My problem now is replacing a previous library with JPA and enhance the way I build the
DAOs.

Regards,

Daniel



On Thu, Apr 16, 2009 at 8:27 AM, Daniel Toffetti <dtoffe@yahoo.com.ar>wrote:

>    I just DON'T WANT to invoke a callable statement or named query in my
> business code, that's why I need a DAO layer. This is what I want to do in
> my business layer:
>
>    Collection<SalesReportLine> reportItems =
> SalesReportLineDAO.query('2009-04-16');
>

I think for a simple case like finding an entity by ID,
SalesReportLine.findById(...) is fine (rather than
SalesReportLineDAO.findById(...)). Here,
SalesReportLineDAO.query('2009-04-16') could be a logically complex query
that makes use of the business rules of the system. So I don't think it
belongs in SalesReportLine or SalesReportLineDAO, I don't know, maybe I have
a different idea of what DAO is for. It belongs in some sort of
"SalesReportLogic" class. But this isn't possible if SalesReportLogic isn't
and @Entity, you can't put NamedQueries in it. (Same goes for
SalesReportLineDAO.) I'm not criticizing your approach, just looking for a
solution to my preferred style.

My understanding is that DAO is to encapsulate the storage mechanism. I'm
looking for a way to seperate business logic that retrieves things from the
data store.

I've never used the DAO pattern. My homegrown web application framework I
would say is a little "too close to the metal". In trying to learn JPA, I
see this pattern of MyEntity and MyEntityDAO. I started following this but
found it frustrating that since MyEntityDAO is not an @Entity, I can't put
@NamedQueries in it. My @NamedQueries are in MyEntity, so why not put
findMyEntity() right on MyEntity? This keeps the method and the query in the
same class. The only problem I have with it is that NamedQueries can contain
complex business logic which should not be mixed with storage of data.

Comments? 
-- 
Daryl Stultz



-- 
View this message in context: http://n2.nabble.com/Looking-for-advice-on-JPA-based-DAO-tp2641707p2651649.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.


Mime
View raw message