On Thu, Apr 16, 2009 at 8:27 AM, Daniel Toffetti <[email protected]>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.
--
Daryl Stultz
_____________________________________
6 Degrees Software and Consulting, Inc.
http://www.6degrees.com
mailto:[email protected]
