Hi Martin, It's always interesting to read your opinion ;-) I agree with you in almost everything, the only thing I disagree with is that, from my point of view, we should enforce (or at least recommend) the Openbravo's developers to use DAO objects for querying/updating the database.
Before DAL, Openbravo's developers only used sqlC [1] for querying/updating the database through JDBC. This tool automatically creates a class based on the queries defined in a *_data.xsql file. Inside this class we had all the code related to the way to query the database (JDBC). Our servlets were totally independent of the code to access the database. This idea is almost the same compare to the DAO design pattern, that's why I think we should use DAO pattern because it's quite similar to our old (and beloved) sqlC classes. Thus, the internal structure of Openbravo (from a development point of view) will keep constant. And to keep the structure constant, my approach to group DAOs will be: - A DAO object per servlet for core, which is equivalent to a *Data class per servlet used before DAL - A DAO object per module. This of course depends on the module's size or structure, but usually with a DAO is enough. Best regards, Víctor Martínez Romanos [1] http://wiki.openbravo.com/wiki/ERP/2.50/Developers_Guide/Concepts/SQLC On Tue, Oct 6, 2009 at 1:51 PM, Martin Taal <[email protected]> wrote: > Hi Victor, > This is an interesting topic. It for sure makes sense to centralize > queries, especially if they are re-used a lot or complexer to maintain. > > However, the DAO pattern has been under discussion (see the links below) > when used together with Hibernate/JPA as these ORM tools make it simple > to talk objects/database directly. In the end it all depends on the needs. > > If you have a simple webpage then it can be backed by a bean/servlet > which does direct HQL queries in the database. If the queries are > complex/generic then it is very logical to put them separately in an > extra service/class/layer. Another question is how to group this > data-access logic, by entity, module or even more global. In your > example Victor you have a data access service per Module which is very > usefull. > > To also give some stronger opinion :-), for me the DAO is fine but the > DTO-pattern (previously often combined with DAO) is not very usefull afaics. > > As a side note, you could also put a different name on the DAO pattern, > people have used the term data service or repository also to denote > similar patterns. > > So imo DAO's are very usefull for efficient coding of queries, however I > would not recommend enforcing a DAO layer to be the single access point > for querying/updating data. Like introducing an OrderDAO and then > tell/enforce that this one should be used always to read/write > SalesOrders. If we need pre-save/post-load processing of objects then > Hibernate offers internal extension points to catch update/load events > which can be used for adding specific application logic for that. > > Just my 2 cents. > > Here are some interesting links about this topic (see also the links in > the blogs themselves): > - > http://blog.xebia.com/2009/05/11/jpa-implementation-patterns-service-facades-and-data-transfers-objects/ > - > http://blog.xebia.com/2009/03/09/jpa-implementation-patterns-data-access-objects/ > > gr. Martin > > Víctor Martínez wrote: >> Hi Rafa, >> >> The diff you have attached will work fine, but I want to recommend you >> a different approach for writing this code. >> >> In the localization and accounting department, we are using in our >> projects a structure based on the "Data Access Object" design pattern >> [1]. The idea behind this design pattern is to keep the servlet (your >> callout) as much independent as possible from the way to retrieve the >> data from the database. This way the servlet is only in charge on >> "using" the data, but it has no idea about where (the database) and >> how (DAL/Hibernate) data have been retrieved. >> >> In the Tax Report Launcher project [2] you have examples of this >> design pattern: >> >> - The TaxReportLauncherDao.java [3] class is the "DAO", i.e. the class >> that knows how to use DAL. Inside this class we have all the methods >> that get the data from the database using DAL (Hibernate) and >> transform the data to the way the servlet is expecting. >> >> - Finally, the servlet must create an instance of the DAO class to use >> its methods to get the data. The OBTL_SE_TaxLauncher.java [4] callout >> is an example. >> >> Notice how we have all the "queries" to the database centralized in >> just one place; if a query is wrong we know exactly where it is; and >> once fixed, we automatically fix all the code that use it. >> Also notice that the servlet is not "polluted" with the DAL code. If >> in the future we want to change Hibernate by other method to get the >> data from the database, we just need to change all the DAO classes, >> but not the servlets. >> >> >> Hope you find it useful. >> >> Best regards, >> Víctor Martínez Romanos >> >> >> [1] >> http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html >> [2] http://forge.openbravo.com/projects/taxreportlauncher >> [3] >> https://code.openbravo.com/erp/mods/org.openbravo.module.taxreportlauncher/file/66b8b5bb21b9/src/org/openbravo/module/taxreportlauncher/Dao/TaxReportLauncherDao.java >> [4] >> https://code.openbravo.com/erp/mods/org.openbravo.module.taxreportlauncher/file/66b8b5bb21b9/src/org/openbravo/module/taxreportlauncher/erpCommon/ad_callouts/OBTL_SE_TaxLauncher.java >> >> >> On Tue, Oct 6, 2009 at 7:01 AM, Rafa Roda @ Openbravo >> <[email protected]> wrote: >> >>> Thank you very much Martin! That worked perfectly :) >>> >>> I attached the new diff that easily permits to save one XSQL file by >>> replacing the query by DAL. >>> >>> I hope that it helps you :) >>> >>> Cheers! >>> >>> Rafa Roda Palacios >>> >>> 2009/10/5 Martin Taal <[email protected]> >>> >>>> Hi Rafa, >>>> Based on quick read of your diff, I think you can replace most of the >>>> where-clause and OBQuery with these lines: >>>> >>>> final PriceList priceList = OBDal.getInstance().get(PriceList.class, >>>> strMPriceListID); >>>> if (priceList != null) { >>>> strPriceListCurrency = pl.getCurrency().getId(); >>>> } >>>> >>>> gr. Martiin >>>> >>>> Rafa Roda @ Openbravo wrote: >>>> >>>>> Hi Openbravo developers! >>>>> >>>>> I've been playing around a bit with DAL replacing an XSQL from a callout >>>>> by a DAL OBQuery. >>>>> >>>>> The callout is SL_Project_PriceList.java [1], a simple callout that >>>>> selects the Currency from the Price List chosen in the Multiphase or >>>>> Service >>>>> Project header. >>>>> >>>>> The diff attached does the job but I would like to know if it can be >>>>> achieved in a cleaner way from a code perspective. >>>>> >>>>> Based on this, I would like to update the How-To Callout example [2] in >>>>> order to use DAL OBQuery instead of an xSQL file. >>>>> >>>>> Thanks for any comment. >>>>> >>>>> Rafa Roda Palacios >>>>> >>>>> [1] >>>>> https://code.openbravo.com/erp/devel/pi/file/74eb0fd11265/src/org/openbravo/erpCommon/ad_callouts/SL_Project_PriceList.java >>>>> [2] >>>>> http://wiki.openbravo.com/wiki/ERP/2.50/Developers_Guide/How_to_develop_a_callout >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Come build with us! The BlackBerry® Developer Conference in SF, CA >>>>> is the only developer event you need to attend this year. Jumpstart your >>>>> developing skills, take BlackBerry mobile applications to market and stay >>>>> ahead of the curve. Join us from November 9-12, 2009. Register >>>>> now! >>>>> http://p.sf.net/sfu/devconf >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Openbravo-development mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/openbravo-development >>>>> >>>>> >>>> -- >>>> >>>> With Regards, Martin Taal >>>> >>>> Openbravo >>>> M: +31 6 288 48 943 >>>> @: [email protected] >>>> Skype: martintaal >>>> >>>> Openbravo Headquarters: >>>> P: +34 93 27 25 947 >>>> F: +34 93 27 25 905 >>>> Address: Edificio Slan, Planta 2a, Landaben, Calle J, 31012 Pamplona, >>>> Navarra, Spain >>>> Mailing address: PO Box 5117, 31010 Pamplona, Navarra, Spain >>>> >>>> >>> ------------------------------------------------------------------------------ >>> Come build with us! The BlackBerry® Developer Conference in SF, CA >>> is the only developer event you need to attend this year. Jumpstart your >>> developing skills, take BlackBerry mobile applications to market and stay >>> ahead of the curve. Join us from November 9-12, 2009. Register now! >>> http://p.sf.net/sfu/devconf >>> _______________________________________________ >>> Openbravo-development mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/openbravo-development >>> >>> >>> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9-12, 2009. Register now! >> http://p.sf.net/sfu/devconf >> _______________________________________________ >> Openbravo-development mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/openbravo-development >> >> > > > -- > > With Regards, Martin Taal > > Openbravo > M: +31 6 288 48 943 > @: [email protected] > Skype: martintaal > > Openbravo Headquarters: > P: +34 93 27 25 947 > F: +34 93 27 25 905 > Address: Edificio Slan, Planta 2a, Landaben, Calle J, 31012 Pamplona, > Navarra, Spain > Mailing address: PO Box 5117, 31010 Pamplona, Navarra, Spain > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Openbravo-development mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openbravo-development > -- -- Víctor Martínez [email protected] ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Openbravo-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openbravo-development
