Discussions

EJB programming & troubleshooting: Entity Beans or Homebrew Persistence framework

  1. Entity Beans or Homebrew Persistence framework (4 messages)

    In a discussion about entity beans(here) I stated that "Using entity beans is, most of the time, as good as using a homebrew persistence"

    What I would like to discuss is: what would you like to have in a homebrew persistence framework?

    What I would like is:
    1.- Easy Lifecycle management (create, load,store,delete)
    2.- Object pooling
    3.- Transaction management over multiple JDBC calls.

    Also, I would like to answer:
    1.- Is there a need for a factory method for the DAO creation?
    2.- How to do the mapping between objects and tables?
    3.- How to handle the "view" objects (ie: how to query the framework for data)?

    Any thoughts?


    Rafael
  2. Rafael,

    I'll try to answer your questions as I see it.

    1. Lifecycle should not be considered in the light of each specific component, I recommend to get rid of OO component model (no need in control for the beans each of which represents record in the table). You can easily perform create/load/store/delete operations by propagating parameters (directly from your presentation tier - you still deal with GET/POST parameters in your servlets, remember?) to DAO that constructs proper SQL statement based on this arguments. We construct objects from ResultSets of this statements. And we don't control their lifecycle - they are created only to be returned back to the client. That's all. Fast lane reader. Good enough for everything.

    2. You can pool everything if there is any need for it. Usually it's not a problem to create a singleton even in EJB container's clustering environment (just keep them in SFSB).

    3. That's easy enough. You can easily do that with JDBC (see my framework description I've just posted).

    Additional questions:

    1. It depends. I.e. I just use simple polymorphism in order to delegate to the chosen DAO. BTW, I use an XML based code generator that has ability to generate DAOs from the Web parameter list and SQL statement templates.

    2. You just know which objects you need to have. SQL does the rest for you.

    3. Each DAO knows how to construct Colletions of JavaBean-type objects from ResultSets.
     
    Alex
  3. I'll add two more points:

    a. Do a little research first to see what homebrews are out there already. A few open source entity models and entity model generators seem to be taking off.

    b. A good homebrew should support generating the entity model _as_ entity beans. Then when the time comes to test performance on a given web server you can decide for yourself whether to have your app use entity beans or the other method.
  4. Alex,
    It's me or this getting more like a dialog between us? :)

    Just two questions:

    >2. You just know which objects you need to have. SQL does
    >the rest for you.
    This means that each object maps to a specific table, or that the SQL to do it is harcoded is some way (inside the code, a property files, xml, etc)?

    >3. Each DAO knows how to construct Colletions of JavaBean-
    >type objects from ResultSets.
    So, for each kind of view I have to create either a new object (DAO) or a new method in the DAO?

    Rafael
  5. Alex,

    It's me or this getting more like a dialog between us? :)

    Well, at least we the ones who're the most interested in the topic... ;)

    Just two questions:

    >2. You just know which objects you need to have. SQL does
    >the rest for you.
    This means that each object maps to a specific table, or that the SQL to do it is harcoded is some way (inside the code, a property files, xml, etc)?

    Object is a result of SQL operation that can effect several tables (and usually it does). SQLs can be hardcoded in a property file or XML or even in the code.

    >3. Each DAO knows how to construct Colletions of JavaBean-
    >type objects from ResultSets.
    So, for each kind of view I have to create either a new object (DAO) or a new method in the DAO?


    Actually, your create one DAO for each part of view, then you can aggregate the result objects from this DAOs and return back to the user as one AggregateVO - this object will be rendered by JSP.

    Alex