DAO design decission

Hi All,
Currently in my j2ee project, we are using hibernate for database access. for this iam using DAO pattern, as follows .
1) will be calling DAO abstract factory pattern from business service, to give DAO factory object.
2) with this object, i will try to create a dao factory object(specific for hibernate or jdbc as necessary).
3) on getting corresponding hibernate/jdbc dao factory object, i will create application specific dao object to interact , ie emplyoeeDAO etc.
I just want to know whether this is a correct approach to handle jdbc also, if in future if we use.
Thanks,
kk
Edited by: krishna_keriti123 on Dec 17, 2008 7:41 PM

Why not invert control? Do you use Spring? That provides a neat way of abstracting your DAO strategy and wiring the dependencies up. The problem I see with using the abstract factory pattern for DAOs as you've described, is the sheer number of lookups business services will have to do. They have to get hold of the factory, and then look up the DAO as well. With dependency injection, they just get built with what they need up-front. You needn't actually use Spring for DI, you could roll it yourself. But coupled with the DAO support, and other supporting services, I think you've got a good case for using Spring here

Similar Messages

  • Struts using DAO Design Pattern ..?Please give an example..... URGENT......

    Dear all,
    I have to develop an application in Struts by using DAO design pattern ..........
    Please give an example on Struts using DAO...................
    Thank you
    Please

    I'm glad you asked. It means Read The Flaming Manual. That'd be the struts manual by the way.

  • Struts using DAO Design Pattern Tutorail

    Can anybody give me a link for the Struts using DAO Design Pattern tutorial
    sample tutorial

    http://javaboutique.internet.com/tutorials/ApacheDAOs/
    Found by using google: strust dao pattern tutorial
    There are more good links using that search...

  • DAO design pattern & Transaction boundaries

    I am using a tool to generate a JDBC tier that applies the DAO design pattern. However, the generated code is based on "autocommit"-strategy, i.e. there is no conn.setautocommit(false)-statement in the code.
    I have added statement so that I can handle the transaction by myself. The DataAccessObject-implementation class does however close the connection before returning. I would like to execute the commit outside of the DAO-implementation.
    Anyone who have been experiencing the same problem?
    Best regards
    Lasse Bergstr�m

    I'm not sure if I fully understand your question.
    However, we usually implement such a scenario by doing autocommit false on the connection object and then passing it to the DAO. Finally do a commit on the connection in the calling class.

  • DAO Design pattern

    Hi,
    what is the advantages of DAO Design pattern over other design patterns?
    Can anybody tel me

    valooCK wrote:
    NANDA wrote:
    Hi,
    what is the advantages of DAO Design pattern over other design patterns?
    Can anybody tel methe answer is none!
    DAO stands for data access object, it is a non oo pattern, oo is data centric, it makes sense for data to access data. it is something created by poor procedural minds who can never understand what oo is.
    you may occasionary use it as a collection of functionalities or utilities, but thou shalt never use in as a pattern in oop!There are as-yet undiscovered tribes living in the Amazon, who knew you were going to say that
    @OP: Please ignore this troll, he doesn't even understand the very basics of OO, as can be demonstrated in the following thread
    http://forum.java.sun.com/thread.jspa?threadID=5273397&tstart=0
    Just ignore him. He only wants attention. He hasn't got the faintest idea how to write even "Hello World", let alone actually do any OO design

  • How to generate report from two tables using DAO design pattern?

    Hi,
    Iam using struts with DAO pattern for my application. According to DAO design im creating model class for each table in my database with getter,setter methods. i have no problem when im generating report from one table. but if have i have to join two tables whatis the better way for doing that? is it good practise to create a new model contains properties from both the tables?
    Please help me
    Thanks in Advance
    Rajesh

    Dear Rajesh,
    As per the pattern you are creating equivalent java objects for every database table under consideration in which each db field will become a private attribute and public getter and setter methods.
    If you have to display data from one table the above approach is sufficient enough.
    But in case your database is normalised ..lets take an example of Bank having Branch and Accounts tables. We dont need to repeat the whole information of the branch for every account in that branch. so we prefer to have a branch id in that table....this approach lot of insertion/deletion/updatation anomlies that may exists with the database...
    now lets come back to our topic....we shall create two java objects 1) Branch 2) Account.....
    When ever u just need to display simple report u can do it staright forward,,,,,now if u want to display branch information along with the account information....the two objects just created are not sufficient
    So i suggest u the following approaches
    1) Create an attribute of type Branch in the Accounts Object......
    This shall serve the purpose of displaying the Btranch information
    2) Create a collection object of type ( Vector or ArrayList) which can have objects of Account in the Branch Object,,,
    Now its upto u how shall u fill up the objects with appropriate sql queries.
    The method that i mentioned is followed by Oracle Toplink and Hibernate ....which provide Object to relation mapping layers.
    Any queries ...revert back to me...
    Mahesh

  • Questions on DAO design

    This is the first time I used DAO design.
    I have a machine class and each machine has a few parts.
    How should I design the DAO? Especially regarding the inner parts.
    Should I create a DAO for machine and for part and put the PartDAO as an atribute of MachineDAO so that I can populate the Machine's parts with the help of PartDAOOr is it better to retrieve the parts directly when retrieving machine by JOINING the 2 tables (inside MachineDAO).
    Or are there other best practices regarding DAO design?
    Please help me,
    Thx in advance,
    David Limanus

    Right sorry. When you think from the user of the DAO
    yes, one DAO should deal with one object. Then when
    you start implementing the DAO, You will try to
    reduce the overall number of tables. I don't agree - the number of tables should be designed according to the data's needs and normalization rules, and the objects according to the problem's needs. Then you map one to the other. I don't understand what you mean by "reduce the overall number of tables".
    But its true
    that I may have 3 different DAOs that access the same
    table. Meaning that one may access the table directly and others JOIN to it? Yes.
    Also, that I have one DAO that uses multiple tables.Meaning JOINs? Yes.
    Actually what I tried was to handle one table from
    one class file. That didn't really work
    either because of the joins and subqueries.
    Inefficient by design: suffers from the (n+1)query
    problem.Could you explain that problem? It seems to work
    well for me and is easily managed.If you measure the performance and find that it meets your service level agreement, then it "works". But it depends on the number of Parts a Machine has, right? If you do one query for each Part, that means one network roundtrip for each one. As the number of Parts gets large, so does the number of network roundtrips. Since network latency is one of the biggest bottlenecks in your app, the more of them you do, the worse your performance.
    A Machine that requires a small number of Parts might perform fine, but if the number increases you might find that performance is unacceptable. Maybe yours is "working well" because your Machines are simple.
    %

  • Help on Factory DAO design... S.O.S.

    Hi
    I have to develop a J2EE application and I have a theoretic question about Factory DAO pattern.
    Consider the following scenario:
    - I have to use a DAO patterns.
    - My database have 120 tables approximately.
    - The system have 20 logical modules approximately the can use whichever table.
    - I associate a Session Bean with Factory DAO class.
    1.- Do I have to implement only one Session-FactoryDao for all the system or one Session-FactoryDao for each logical module.
    2.- Can my session contain only one FactoryDao or many FactoryDao (that�s correct?)
    3.- I implement only one interface (implClassDao) for the FactoryDao class. Is possible implement many interface for the FactoryDao class?
    4.- What design strategy I have to follow?
    Thanks and I hope yours answers.
    Isra.

    Implement one factory for each of the logical modules. This is an advice and strictly an advice. There are more than one way of doing the same thing correctly - I feel the above is the right way, given your situation.
    Ironluca

  • Design decission for multilingual support using JSF

    I am in the process of doing a refactoring of a web application written using Model 2 design (JSP, Servlet). The web application should support diffrent languages and somtimes different page layout and validation rules based on country.
    The problem with the application today is that the jsp-pages contain numerous scritlets with conditional statement whether a html-element should be visible or not. All validations are done in javascript which also has a country dependency.
    I have been looking at JSF/facelets as a solution to the problem. I believe that the component model of JSF in conjunction with the templating in Facelets could do the trick but I am struggling a bit with which "Best Practices" to use.
    I would very much appreciate if anyone has faced a similar problem and could share some start-up recommendations.
    /Jörgen

    i18n is very good handled in JSF. Read chapter 2.5.2 and on of the JSF specification: [http://jcp.org/aboutJava/communityprocess/final/jsr252/index.html] (pick 1st download).

  • JPA DAO Design Pattern

    Hi all,
    I have one abstract DAO class and every sessionbean DAO will extend it.
    here is sample code.
    public abstract SuperDAO{
    @PersistenceContext (unitName = "stars21db")
    private EntityManager em;
    public getEM(){
    return em;
    Here is Session Bean DAO
    @Stateless
    @Local
    public class CapDaoSessionBeanBean extends SuperDAO implements CapDaoSessionBeanLocal {
    public CapDaoSessionBeanBean() {
    public getCustomer(){
    }

    Code is fine, but the wording isn't the right one. You are about to build a Facade. DAO were originally build as the ones who know how to interact with the database, with JPA this is handled by the EntityManager. Therefore the DAO pattern doesn't apply...
    --olaf                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • ANN: New Design Pattern (DAO)

    Hello,
    Thanks for your overwhelming response to our previous sample applications demonstrating various [url http://www.oracle.com/technology/sample_code/tech/java/j2ee/designpattern/index.html]design patterns.
    Continuing with the series, this month we have showcased the [url http://www.oracle.com/technology/sample_code/tech/java/j2ee/designpattern/dataaccesstier/index.html]Data Access Object (DAO) Design Pattern which is considered as a best practice for applications accessesing the database or the underlying persistence layer from the business tier.
    The DAO implements the access mechanism required to work with the data source. The data source could be a persistent store like an RDBMS, an external service like a B2B exchange, a repository like an LDAP database, or an XML Repository. Using the scenario of web based News Application, this sample application demonstrates the effective use of this pattern.
    [url http://www.oracle.com/technology/sample_code/tech/java/j2ee/designpattern/dataaccesstier/index.html]Download the sample application to learn more about this pattern.
    More Sample Applications are available at [url http://www.oracle.com/technology/sample_code/index.html]
    http://www.oracle.com/technology/sample_code/index.html
    Thanks,
    Rajat
    OTN Team

    Hi
    This is because you are not using the latest jdbc driver version. Either use the latest ojdbc14.jar downloadable from the location given in the readme(Oracle Database 10g (10.1.0.2.0) drivers),
    Or simply comment this part in the code.
    Also you may just replace the close method call with ods=null;
    Hope this helps
    Shrinivas

  • DAO object Design Pattern

    i have to develop a web base applecation which is database indepandent, to achive this functionlity i have to use DAO design pattern.
    can some one explane me more about this............................

    Data Access Object:
    Java BluePrints - Data Access Object
    JavaWorld: Write once, persist anywhere

  • Use of synchronisation with the SUN DAO Pattern

    With reference to the design pattern Core J2EE Patterns Data Access Object: http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
    I am writing a DAO package to handle access to multiple datasources at a record level (e.g. user records may be located at datasource A, but customer records at datasource B). The role of the package is to provide DAO objects to clients (e.g. business objects in an application package to come later). Nothing too unusual. I have digested the SUN design pattern for DAO.
    As I understand it, it can be summarised as: client code calls on an abstract DAOFactory to provide the appropriate concrete DAOFactory . The concrete factory can then supply the correct DAO object. The concrete DAOFactory is also responsible for providing the connection services (such as pooling). So far so good. I have pasted the concrete DAOFactory code form the design pattern page:
    // Cloudscape concrete DAO Factory implementation
    import java.sql.*;
    public class CloudscapeDAOFactory extends DAOFactory {
    public static final String DRIVER=
    "COM.cloudscape.core.RmiJdbcDriver";
    public static final String DBURL=
    "jdbc:cloudscape:rmi://localhost:1099/CoreJ2EEDB";
    // method to create Cloudscape connections
    public static Connection createConnection() {
    // Use DRIVER and DBURL to create a connection
    // Recommend connection pool implementation/usage
    *** can a connection pool be implemented in a static method? ***
    public CustomerDAO getCustomerDAO() {
    // CloudscapeCustomerDAO implements CustomerDAO
    return new CloudscapeCustomerDAO();
    public AccountDAO getAccountDAO() {
    // CloudscapeAccountDAO implements AccountDAO
    return new CloudscapeAccountDAO();
    public OrderDAO getOrderDAO() {
    // CloudscapeOrderDAO implements OrderDAO
    return new CloudscapeOrderDAO();
    I have some questions on this overall design.
    1)     The design for the factories as given looks inelegant and requires upgrading each time a new DAO is added ? much better surely to dynamically generate the DAOs using reflection. If I implement a mapping of data type to data source using a properties file (typical entry, Key = Role, Value = Oracle), the use of abstract and concrete factories can be reduced to a single factory. The single factory reads in the mapping on initialisation and provides a method getDAO to client code. The method takes the data type, looks up the data source and returns the correct DAO class using reflection (e.g. the client passes ?Role? to getDAO and the factory returns Oracle + DAO + Role = OracleDAORole.class). This also has the advantage that the client code does not need to specify the data source to use. I have read some forums and note that performance is an issue with reflection; however I have not seen any significant difference in performance between using reflection to generate a class name and using a factory pattern (e.g. testing just the code paths, for 10 million operations, both reflection and factory took 2.5 seconds each). Does anyone have any opinions on the pros and cons of this approach?
    2)     If we go with the original DAO design (ignoring 1 above) I have marked the part of the concrete factory code that I have a problem with: using a connection pool in the concrete factory. As the factory?s createConnection method is static, you cannot use NotifyAll or Wait methods here, and therefore you cannot synchronise access to the pool (correct?). I have therefore created a separate connection pool class (which uses the singleton pattern and uses synchronised methods to manage the pool). Is this a sensible way to approach this or is there a clever way to synchronise access to static methods?
    Thanks in advance - Alan

    These resources may be helpful:
    http://daoexamples.sourceforge.net/related.html
    http://daoexamples.sourceforge.net/index.html

  • Mapping Design  - SOAP body content needs to be different between test and production

    Hello,
    We are integrating with a 3rd party SOAP receiver who uses the same web service URLS for test and production.
    So to differentiate they exposed 2 web services which do the same thing but have different root and payload node names...along with account details.
    For example, for production our SOAP XML must follow pattern like:
    <Envelope>
    <Body>
    <appRequest>
    <userID>produser</userID><password>prodpwd</password>
    <appPayload>
    <?xml>
    blah blah this XML is the same between test and production
    </xml>
    </appPayload>
    etc
    But for their testing we must use:
    <Envelope>
    <Body>
    <appRequestTest>
    <userID>testuser</userID><password>testpwd</password>
    <appPayloadTest>
    <?xml>
    blah blah this XML is the same between test and production
    </xml>
    </appPayload>
    etc
    So I'm trying to think of a good way to handle this difference in one set of mappings that we can use in our 3 PI platforms Dev / Test / Prod
    Since these differences are in the SOAP Body does it need handled in mapping or is there a way to handle it in the Adapter Config which is naturally different between our environments (mapping we like to keep the same).
    What is a smart way to handle this scenario?
    Many thanks,
    Aaron

    I second Artem when he states that this is a bad design decission from the caller's side.
    However this is not gonna help you in the current situation, right?
    The problem you are facing is that by poor design the message does not have a root node which you may use to handle occurences. Let me explain further
    You would be good if prod message looked like so
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
    <soapenv:Header/>
    <soapenv:Body>
      <appData>
       <appRequest>
       </appRequest>
      </appData>
    </soapenv:Body>
    </soapenv:Envelope>
    and test message looked like so
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
    <soapenv:Header/>
    <soapenv:Body>
      <appData>
       <appRequestTest>
       </appRequestTest>
      </appData>
    </soapenv:Body>
    </soapenv:Envelope>
    --> Then you would have been able to specify occurence of <appRequest> and <appRequestTest> as 0..1
    So I think you have (besides what Artem already pointed out) 2 other options:
    1. activate "do not use SOAP envelope" on sender SOAP channel and then designing the data types like above
    2. Use HTTP instead of SOAP adapter and designing data types like above
    Hope I didn't miss something crucial :-)
    Cheers
    Jens

  • DAO pattern and Java Persistence API

    Hi
    This is a question for anyone who might be familiar with the standard DAO design pattern and the Java Persistence API (JPA - part of EJB3). I'm new to this technology, so apologies for any terminology aberrations.
    I am developing the overall architecture for an enterprise system. I intend to use the DAO pattern as the conceptual basis for all data access - this data will reside in a number of forms (e.g. RDBMS, flat file). In the specific case of the RDBMS, I intend to use JPA. My understanding of JPA is that it does/can support the DAO concept, but I'm struggling to get my head around how the two ideas (can be made to) relate to each other.
    For example, the DAO pattern is all about how business objects, data access objects, data transfer objects, data sources, etc relate to each other; JPA is all about entities and persistence units/contexts relate to each other. Further, JPA uses ORM, which is not a DAO concept.
    So, to summarise - can DAO and JPA work together and if so how?
    Thanks
    P.S. Please let me know if you think this topic would be more visible in another forum (e.g. EJB).

    Thanks, duffymo, that makes sense. However ... having read through numerous threads in which you voice your opinion of the DAO World According to Sun, I'd be interested to know your thoughts on the following ...
    Basically, I'm in the process of proposing an enterprise system architecture, which will use DAO as the primary persistence abstraction, and DAO + JPA in the particular case of persistence to a RDBMS. In doing so, I'd like to illustrate the various elements of the DAO pattern, a la the standard class diagram that relates BusinessObject / DataAccessObject / DataSource / TransferObject (http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html). With reference to this model, I know that you have a view on the concept of TransferObject (aka ValueObject?) - how would you depict the DAO pattern in its most generic form? Or is the concept of a generic DAO pattern compromised by the specific implementation that is used (in this case JPA)?

Maybe you are looking for