Question about DAO pattern

Greetings.
If I'm using EJB's in my application when does DAO fits in?? I mean, it is DAO an alternative to EJB's or a complement ??
Thanks in advance.

DAO fits in if you are using entity beans using bean managed persistence. In this case, the DAO brokers the database calls during the EJB's lifecycle. The other instance when you would use DAO would be if you forgo entity beans altogether. In this model, stateful or stateless session beans would use DAO's to broker the database calls directly, outside of the normal entity bean lifecycle. The DAO pattern can also be used with POJO's (plain 'ole Java objects).
The only instance where DAO would not apply is in the case of a container managed entity bean. In this case, there is no need to write a DAO, as the container will persist the bean for you.
- Saish
"My karma ran over your dogma." - Anon

Similar Messages

  • Questions about DAO pattern

    Hi,
    I am a junior programmer and I am trying to understand somewhat more about best practices and design patterns.
    I am looking for more information regarding the DAO pattern, not the easy examples you find everywhere on the internet, but actual implementations of real world examples.
    Questions:
    1) Does a DAO always map with a single table in the database?
    2) Does a DAO contain any validation logic or is all validation logic contained in the Business Object?
    3) In a database I have 2 tables: Person and Address. As far as I understand the DAO pattern, I now create a PersonDAO and an AddressDAO who will perform the CRUD operations for the Person and Address objects. PersonDAO only has access to the Person table and AddressDAO only has access to the Address table. This seems correct to me, but what if I must be able to look up all persons who live in the same city? What if I also want to look up persons via their telephone numbers? I could add a findPersonByCity and findPersonByTelephoneNumber method to the PersonDAO, but that would result in the PersonDAO also accessing the Address table in the database (even though there already is an AddressDAO). Is that permitted? And why?
    I hope someone can help me out.
    Thanks for your time!
    Jeroen

    That is exactly what I am trying to do. I am writing it all myself to get a better understanding of it.
    Please bear with me, because there are some things I dont understand in your previous answer.
    1) Each BO validates his corresponding DTO and exposes operations to persist that DTO. Each DTO will be persisted in the database via his corresponding DAO. So this would be:
    - in PersonBO
    public void save(PersonDTO personDTO) {
    this.validate(personDTO); // does not validate the nested address DTOs
    this.personDAO.save(personDTO); // does not save the nested address DTOs
    - in AddressBO
    public void save(AddressDTO addressDTO) {
    this.validate(addressDTO);
    this.addressDAO.save(addressDTO);
    Am I viewing it from the right side now?
    2) Imagine a form designed to insert a new person in the database, it contains all fields for the Person DTO and 2 Address DTOs.
    How would I do this using my Business Objects?
    This is how I see it:
    // fill the DTOs
    daoManager.beginTransaction();
    try {
    personBO.setDao(daoManager.getDao(PersonDAO.class));
    personBO.save(personDTO); // save 1
    addressBO.setDao(daoManager.getDao(AddressDAO.class));
    addressBO.save(personDTO.getAddress(1)); // save 2
    addressBO.save(personDTO.getAddress(2)); // save 3
    daoManager.commit();
    catch(Exception e) {
    daoManager.rollBack();
    If I insert the transaction management inside the DAOs, I can never rollback save 1 when save 2 or save 3 fail.
    It can be that I am viewing it all wrong, please correct me if that is the case.
    Thanks!
    Jeroen

  • Questions about DAO

    Hi,
    we have some questions about DAO, Someone knows the answers?
    In versión 10g, one could create DAOs (Data Access Objects) from DB and then they could use them for extract and store data.
    In BPM 11g, how one could store information in the DB? How can they integrate them?
    Thanks in advance
    Antonio

    In 11g Database Adapters are used for direct access to the database. You add a DB adapter reference to your composite then this gets exposed as a service that can be invoked from the BPMN/BPEL process.
    Some documentation can be found here:
    http://download.oracle.com/docs/cd/E14571_01/integration.1111/e10231/adptr_db.htm#BGBBHJGC

  • Question about bridge pattern

    its definition is "decouple an abstraction from its implementation so that the two can vary independently". I don't understand what "abstraction and the implementation vary independently" really mean and how .
    Before another question pls see the below class diagram of bridge pattern:
    http://images.cnblogs.com/cnblogs_com/zhenyulu/Pic91.gif
    My question is whether not using abstraction and just keeping implementation hierarchy can do the same thing? Interface and its implementation itself(polymorphism) can make extending easily and be well subject to open-closed principle,can't they?
    Sorry for my bad English.
    Edited by: fxbird on 2011-7-17 上午5:13

    fxbird wrote:
    jschell wrote:
    fxbird wrote:
    I think it's very common in j2ee development. Certainly isn't if someone is using a container.
    If someone is creating a container then I would suspect that such a pattern might be useful.
    However if someone is creating a container then there are going to be a lot of useful patterns. And lot of classes as well.
    And in total of the entire scope of creating a container the bridge would be a very small part.
    So it certainly isn't going to be "common".Hello jschell , what do you mean by 'container'? You phrased your comment about J2EE. A common idiom is to refer to a J2EE (actually newer name is JEE) server as a JEE container. Not sure why specifically that word is used but maybe because such servers are said to 'contain' applications.
    In my previous reply, the architecture I mentioned is ss(spring+struts2.x),the pattern I mentioned is a standard way. You either do not understand what I said or you do not understand what happens in those implementations.
    If I have 100,000 classes and 3 of them are implementing the bridge pattern then it is not "common".
    If I have 100,000 classes and 3,000 of them implement many bridge patterns (and not generated) then one could say it is "common".
    And having done some JEE applications I seriously doubt there is an implicit need to use the bridge pattern.
    The bridge pattern is intended to deal with a complex situation. Since there are more simple JEE applications than complex ones then it seems unlikely that there is a "common" need for it in JEE applications.
    Actual I've not been understood why it's used this way---define business interface, from my perspective, it doesn't have to define it, simply writing a business class and calling dao method is enough. I assume bo interface thing is a bridge pattern.I don't know why they would use the bridge pattern nor even if they really do. I wouldn't be surprised that it is used and I can also suppose that the use would be a good idea. Although it is quite possible as well that it is used incorrectly in some places.

  • Question about design pattern - business delegate

    hi guys
    i have got a question to ask about the delegate pattern. usually, we use it to decouple between presentation client and businessservice tiers. for instance, the service tier has an session ejb, and delegate wrapps the ejb. and the web client calls delegate to access service. is the delegate only used by the presentation tier? within the service tier, we can have many ejbs that work together to get tasks done. do we still use delegates in the service tier? what is ur suggestion? thanks

    Try the Patterns and OO Design forum.

  • Question about design pattern - business delegate: repost

    hi guys
    i have got a question to ask about the delegate pattern. usually, we use it to decouple between presentation client and businessservice tiers. for instance, the service tier has an session ejb, and delegate wrapps the ejb. and the web client calls delegate to access service. is the delegate only used by the presentation tier? within the service tier, we can have many ejbs that work together to get tasks done. do we still use delegates in the service tier? what is ur suggestion? thanks

    thanks, but i don't think i follow what u said.
    bascially i was asking if it was still a good idea to use delegates to communicate between ejbs the same way presentation tier calls service tier. i.e. SessionEJBA calls DelegateB to access SessionEJBB. or SessionEJBA calls SessionEJBB directly including the lookup, etc.

  • Question about commond pattern

    Hi!
    can somebody tell me about any good resource where i can get knowledge of designing controller on basis of command pattern and an example will help me a lot....
    I want to develop a controller for my application which except's data from swing client and calls the appropriate business components (session beans) to perform the requested task , asked by customer.....
    Also i need to design Factories for my objects and need good resource to get started from....
    thanx in advance
    sajjad ahmed paracha

    Also take a look at Struts on apache.org. You can either use Struts directly or, if you want to develop your own, look at how they architected things as a starting point.
    - Saish

  • Copyright Question about Adobe Patterns

    I have created illustrations for a book and am using Adobe Photoshop Elements to "color in" my drawings. In addition to the patterns which came with my program, I have downloaded patterns from Adobe Exchange. How would you suggest I reference/give credit to Adobe in my publication since these patterns are under copyright protection?

    Unless you sell it as your own creation (that is the pattern template/ swatches, not the result), the usage of provided content is covered in the EULA. No need to make any extra mention of specific stuff beyond perhaps a generic © Adobe for the relevant parts. For third-party content that may be different, but you should find the relevant info from the authors there...
    Mylenium

  • Question about ServiceLocator pattern

    Hi,
    I was wondering what would be the most approproate way to modify the serviceLocator pattern (from the core j2ee patterns book) to handle multiple initialContext? I.e, how do I modify the ServiceLocator to get the home from multiple remote servers?
    Do I get the client to pass in the InitialContext to be used?
    If I cache the homes - what should you use as the key? I.e. what can uniqeuly identify an InitialContext?
    Cheers,
    Nim

    An InitialContext is probably uniquely identified by the provider URL. I'd rather set up some kind of mapping, though, so that you just say "service this" and "service that", and the ServiceLocator, through configuration info, figures out what JNDI service to lookup as well as what to ask for.

  • A question about singleton pattern

    Will a singleton instance be a bottleneck of an application when many client address this instacne?
    and How can I do to deal with this problem?
    help me!

    Unless the singleton has synchronized methods or blocks of code that are synchronized there should be no bottle neck, as multi threads can access it at the same time.

  • Implementing DAO Pattern in ABAP

    This discussion implement DAO pattern asked the question of how to develop a DAO pattern in ABAP but i'd like to go a little deeper.
    The only answer given suggested the following design pattern:
    I don't have an coded example here, but isn't it sufficient for this pattern  to build an interface with some get- and set-methods? This interface can be implemented by several classes with different data retrieval logic. Then a static factory-method could do the job to decide during runtime which actual class is instantiated, returning the interface.
    Can anyone give an abstract description of this implementation relative to an SAP module (How would one approach this implementation in MM, PM, FICO, HR)
    Can anyone see any issues in this design?
    Can anyone provide an alternate design?
    Are we missing any steps?
    Together we can build a solid abap DAO everyone can use.

    I started to read about DAO pattern some days ago and found this great blog post:
    ABAP Unit Tests without database dependency - DAO concept
    I am starting to implement unit test in my developments and DAO pattern seems to be a clever choice.
    Regards,
    Felipe

  • DAO pattern question

    According to the DAO pattern, all fields of the table has to be put in the class, e.g. if I have a table called customer, I have to create a Customer class and then I have another class called CustomerDAO class. In CustomerDAO, I should have a method called getCustomer that returns Customer. But if my table is quite large, and I don't need to get all the attributes of the customer every time, what approach should I use, do I define another method to return, e.g. customer name. customer age etc.? Is there any standard convention?
    Thanks

    hi,
    according to my understanding, u should use Value Object pattern.
    for Example:
    In Customer table if u have Id, name.
    then u have CustomerVO in which u have the following code.
    public class CustomerVO
    private Long id;
    private String name;
    public Long getID()
    return this.id;
    public String getName()
    return this.name;
    public void setID(Long id)
    return this.id=id;
    public String setName(String name)
    return this.name=name;
    So now u have craete object of CustomerVO and get ur required fields only and Enjoy!!!!!!!!!

  • More information in DAO pattern

    Could u send me the document more detail about DAO in Petstore
    I have error when I customize Petstore:
    I replace searchItems function with searchFullDocument But I have error as follows:
    javax.servlet.ServletException: An error occurred while evaluating custom action attribute "value" with value "${catalog.searchFullDocument}": An error occurred while getting property "searchFullDocument" from an instance of class docman.catalog.client.CatalogHelper
         at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:471)
         at jasper.simpleCatalog_jsp._jspService(_simpleCatalog_jsp.java:489)
         at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at com.iplanet.ias.web.jsp.JspServlet$JspServletWrapper.service(JspServlet.java:552)
         at com.iplanet.ias.web.jsp.JspServlet.serviceJspFile(JspServlet.java:368)
         at com.iplanet.ias.web.jsp.JspServlet.service(JspServlet.java:287)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at org.apache.catalina.core.StandardWrapperValve.invokeServletService(StandardWrapperValve.java:720)
         at org.apache.catalina.core.StandardWrapperValve.access$000(StandardWrapperValve.java:118)
         at org.apache.catalina.core.StandardWrapperValve$1.run(StandardWrapperValve.java:278)
         at java.security.AccessController.doPrivileged(Native Method)
         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:274)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:212)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:203)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
         at com.iplanet.ias.web.connector.nsapi.NSAPIProcessor.process(NSAPIProcessor.java:157)
         at com.iplanet.ias.web.WebContainer.service(WebContainer.java:598)
    Root Cause
    javax.servlet.jsp.JspException: An error occurred while evaluating custom action attribute "value" with value "${catalog.searchFullDocument}": An error occurred while getting property "searchFullDocument" from an instance of class docman.catalog.client.CatalogHelper
         at org.apache.taglibs.standard.lang.jstl.Evaluator.evaluate(Evaluator.java:146)
         at org.apache.taglibs.standard.lang.jstl.Evaluator.evaluate(Evaluator.java:165)
         at org.apache.taglibs.standard.lang.support.ExpressionEvaluatorManager.evaluate(ExpressionEvaluatorManager.java:112)
         at org.apache.taglibs.standard.tag.el.core.ExpressionUtil.evalNotNull(ExpressionUtil.java:85)
         at org.apache.taglibs.standard.tag.el.core.SetTag.evaluateExpressions(SetTag.java:147)
         at org.apache.taglibs.standard.tag.el.core.SetTag.doStartTag(SetTag.java:95)
         at jasper.simpleCatalog_jsp._jspService(_simpleCatalog_jsp.java:384)
         at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at com.iplanet.ias.web.jsp.JspServlet$JspServletWrapper.service(JspServlet.java:552)
         at com.iplanet.ias.web.jsp.JspServlet.serviceJspFile(JspServlet.java:368)
         at com.iplanet.ias.web.jsp.JspServlet.service(JspServlet.java:287)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at org.apache.catalina.core.StandardWrapperValve.invokeServletService(StandardWrapperValve.java:720)
         at org.apache.catalina.core.StandardWrapperValve.access$000(StandardWrapperValve.java:118)
         at org.apache.catalina.core.StandardWrapperValve$1.run(StandardWrapperValve.java:278)
         at java.security.AccessController.doPrivileged(Native Method)
         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:274)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:212)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:203)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
         at com.iplanet.ias.web.connector.nsapi.NSAPIProcessor.process(NSAPIProcessor.java:157)
         at com.iplanet.ias.web.WebContainer.service(WebContainer.java:598)

    Hi,
    You can get more info on the DAO pattern at http://java.sun.com/blueprints/patterns/DAO.html
    and also some implementation details of the petstore are descibed at http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/sample-app/sample-app1.3.1.html
    Also, you might want to ask this kind of question at
    http://archives.java.sun.com/archives/j2eeblueprints-interest.html
    hope that helps,
    Sean

  • 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)?

  • About DAO

    I have read something about DAO with the help of some sites. But I didnt clearly understand "In what scenario, we use them"?? If we dnt use this DAO concept, what happens?? Im not asking "HOW do we implement DAO", but my question is "WHY do we use DAO "..I got an answer for "how", but I didnt clearly understand for "why"..Please tell me with some clear explanations instead of single line answers.

    Well, there are really two high level patterns here. Assuming you are going from something like a service based architecture, you will either go service -> dao -> domain object. Or you will go service -> domain object -> dao. I think the first one is a bit easier to understand.
    If you opt for the first option, the service will create the dao (which should be stateless, e.g., no instance variables that are not static and final). You then call a method on the dao (say 'selectFoo()') passing in a primary key and having Foo returned. The other common use would be to create a new instance of Foo, in which case the service would call something like insertFoo() which would return your new object.
    The second option involves just a bit more indirection. On Foo, you would place methods such as update()/save(), delete(), etc. You still need a way to get an instance of Foo. So, you can either create an AbstractFactory or put static methods on Foo such as getInstance() and newInstance(). Foo will delegate its calls to a dao for the actual database operations.
    Now, in the first design, you have separated as much as possible the domain logic from the persistence logic. (You normally have to make a compromise such as putting the primary key of Foo in the domain object, since you need to let the dao know how to update or delete the record). The downside is that you now have to provide a number of getters and setters (or additional constructors) for Foo for the dao to use.
    In the second design, you have mingled the domain and persistence logic a lot more. However, since the methods are all defined on Foo, you can get away with far fewer getters/setters/constructors than in the first design. In fact, with the second design, you really do not need a DAO at all. You can leave the persistence methods completely within Foo.
    One advantage the first design has over the second design (at least superficially) is that you can have multiple dao's all creating a Foo from different sources (say, an Oracle database, a MySql database, a XML file, etc.) In my experience, most objects are persisted in a single way. You can still opt for the second design and have multiple persistence strategies. In this case, you would have a series of helper classes within Foo (nested, inner classes).
    The choice is up to you. Some people really want to move the persistence logic out of the model and make it a separate tier. That pushes you, a bit, torwards design 1. Some people really want to keep encapsulation, and this pushes you a bit towards design 2. There is no right or wrong answer, and you can mix both styles in your application.
    For the dao's themselves, you also have a number of options. You can keep them public objects in their own packages and create a separate persistence tier. Or you can keep the dao's in the same package, make them non-public where possible, and use them simply as helper objects for the dao. Finally, you can eliminate the dao altogether via anonymous/inner classes.
    In terms of how the dao is designed on a class level, it depends on whether you want to use vanilla jdbc, an orm such as hibernate or jpa, or a hybrid such as iBatis. Generally, all of them will either need the information needed to establish a connection. Generally, they will need to clean up resources such as statements, result sets and connections.
    You will likely want to use a connection pool, such as Jakarta Commons DBCP. This improves efficiency and moves the connection logic out of java and into configuration. If you opt for a container (whether J2EE or Spring or something similar), the whole picture gets a lot easier. These will generally clean up resources, perform transactional logic and obtain connections via either configuration or annotations. http://static.springsource.org/spring/docs/2.0.x/reference/jdbc.html.
    So, in a roundabout way of answering your question, there is no "harm" in not using dao's. Generally, a database will outlive the applicaation that created the data. So, separating persistence from domain logic has additional value there. You also gain the benefit of concentrating on SQL in one set of classes and remaining in the java world for your other objects. It also can help somewhat in reducing the size of your domain model classes.
    No right or wrong, it's just a convention to use them.
    - Saish

Maybe you are looking for