> Tell me if you agree that it would be better to have a DAO's > loadSomeData() methods return only application objects, rather than > JDBC ResultSets. That way, if the structure of the database changes (or > you get the data from somewhere besides a database) the DAO can isolate > that change.
Why could you not accomplish the same encapsulation with JDBC result sets? It's possible to write a JDBC ResultSet and/or driver that does not get its data from a relational database. > The only dilemma I am having is that if the EJB or other "service" > component using the DAO provides nothing more than data retrieval > methods, nearly all your code is in the DAO so what did the DAO buy me? Not much it sounds like. I think the proper place for the DAO pattern is in an application that does much more than data retrieval. For example, a GUI data entry application would have a significant amount of code dedicated to the user interface. In that case, it would be advantageous to encapsulate all the data retrieval code in a DAO. Mike =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
