EJB Design for complex Objects

Discussions

EJB design: EJB Design for complex Objects

  1. EJB Design for complex Objects (11 messages)



    EJB Design Issue

    Hi,
    I’m using “Session Bean as Fa├žade to Entity Beans “ Pattern, where I’m wrapping all entity beans with Session Beans.

    I read it somewhere, if object relation ship is complex and if data is retrieved from different tables to form an object, it is advisable to code all the SQLs in Session Bean with out using any Entity Beans. I agree, it will improve performance and it avoids transaction overheads of Entity beans.

    this design is ideal if we are doing only read from database, what is the ideal design if I need to update/create ( insert new rows in table ) … I thought it advisable to use Entity beans in this situation where we need transaction controls, since my object relation ship is 1 to many it will reduce performance.

    Example :

    My Customer Object gets data from both customer table ( customer information is stored ) and Orders table ( where current orders are stored for a customer ) , Customer to Orders is 1 to many relationship.



    Objects :

    Public class Customer {
     
            
            private String name;
            private String CustID;
    private String address;

      


          }


            public class Orders {
            
            private String CustID;
            private String orderNumber;
            private String productID;


         }

     
      Public class CustomerOrders extends Customer {
     
            
    private Vector custOrders;

    }


    in my existing design I have,

    CustomerSessionBean: Session bean, access customer Entity Bean and orders Entity Bean to populate data to CustomerOrders ( no sqls in this session bean ). Based on customer ID, access Customer Entity Bean populates information on CustomerOrders object. Access Orders Entity bean to get Enumeration/collection of orders, populates orders object as vector in CustomerOrders object.

    CustomerBean : Customer Entity bean , returns Customer object
    OrdersBean : Orders Entity bean, returns Enumeration of Orders object



    please let me know any better suggestions for this design.

    Thank you ,
    Subhash

    Threaded Messages (11)

  2. EJB Design for complex Objects[ Go to top ]

    I would have designed this relationship like this:

    Customer - Entity Bean
    Order - Dependent Lifetime Object of Customer
    CustomerOrder - Value Object

    With this design, you can keep all the behavior that needs to be remoted in Customer bean and can avoid overhead of remote calls to Order and CustomerOrder. I see no point in implementing Order as Entity bean, instead you already have CustomerOrder that you can pass to client by value (value object) for making the client access to order state information.

    Please let me know how did you do with this design.

    Hope this helps,
    Reema.
  3. EJB Design for complex Objects[ Go to top ]

    Take a look at your object model again. "CustomerOrder" is not a special kind of a Customer and so, using inheritance here is not a very good idea. I would rather use a Vector in "Customer" object for orders, creating an association relationship.

    I also like Reema's suggestion to use Entity Bean/ Dependent objects combination. (All of us are waiting to see how EJB 2.0 will handle these dependent objects). If you are prepared to go with BMP and do not have a need to manage TXNs across multiple Entity Beans, you might as well expose the "Customer" Entity bean rather than go through a Stateless bean...
  4. Hi Reema,
    I like the design - but how would you populate the Order & CustomerOrder collections? Use some framework ontop of JDBC?
    Cheers.
    Ant.
  5. Hello Anton,

    You have got three choices to implement populating Order and CustomerOrder collections in Customer entity bean.

    1. Use JDBC inside Customer Entity Bean, if at all your Customer bean is BMP. If you follow this approach, your job can be eased by using some of the O/R tools (I believe so!)

    2. Wait till Persistence Managers (an EJB 2.0 Container Module) come out for your specific application server. They are supposed to give persistence, relationships and dependent objects' support for CMP entity beans

    3. You can check out JDO for implementing dependent objects. I dont know how far is that viable, since I haven't used them so far. But this article (http://onjava.com/pub/a/onjava/2001/03/29/ejb.html) claims that JDO is an option to look at while implementing low-level resource access code for components that don't have to be remoted. They are based on connector architecture.

    Hope this helps,
    Reema.
  6. Hi Reema:

    Just one small question: the Customer entity bean
    in your suggestion will be a BMP and not a CMP. correct?

    Vaithi
  7. Hello Vaithi,

    Yes BMP is the best way to do it for finer control.

    Hope this helps,
    Reema.
  8. Hi Reema,
    Thanks for y'r reply. I've more qns. for you.

    Why do you need Order as dependent life cycle object?
    Can't you straightaway have CustomerOrder as the
    dependent lifecycle value object inside the Customer
    independent object?
    While the major Customer entity bean maps to a row in the
    Customer table, this CustomerOrder dependent lifecycle
    value object will be mapping to those rows in the
    Order table that are related to the single row of the
    Customer table.
    In essence, there need not be any Order object mapped
    to the physical Order table.
    A collection of the CustomerOrder dependent value object
    can be passed to the client.
    One thing though: the lifecycle of this CustomerOrder dependent value object inside the Customer object
    should be intelligently managed so that it doesn't
    add much to the overhead.

    I'm expecting y'r valuable comments Reema.
    Vaithi
  9. Hello Vaithi,

    I thought on the mappings you suggested and they sound good. You suggested getting rid of Order as dependent lifecycle object and making CustomerOrder (whose class structure is exactly same as Order) as the dependent lifecycle value object. Still there is one input I would like to give on this.

    You cannot actually make CustomerOrder as dependent "lifecycle" value object, although that can behave as details value object. Reason it is not dependent on the lifecycle of Customer anymore since it (CustomerOrder) had been passed by value to the client. How are you going to manage its lifetime right there from the server, once it had been marshaled to the client? In fact, the client code will have to make sure now, to de-reference CustomerOrder object, once it calls remove() on the remote interface of Customer entity bean.

    So this reduces our design to having Customer Entity bean and CustomerOrder details value object.

    Rest everything seems to be fine with your design. Go for it!

    Cheers,
    Reema.
  10. Hi Reema:

    Thanks for your thoughts.

    I still insist that CustomerOrder will be a dependent
    lifecycle value object. The term lifecycle here means
    that CustomerOrder object's lifecycle will depend on the
    Customer entity's lifecycle. CustomerOrder will not have
    an independent life-cycle, that is, its life is neither controlled by server nor triggered by client. Its
    lifecycle is internally controlled by the
    Customer entity within itself.
    When it comes to marshalling to client, CustomerOrder will
    be remoted as an immutable value object (no set methods)
    from the Customer entity so that the client cannot fiddle
    with its life. I should have mentioned this in my earlier message.
    The dependence of CustomerOrder's lifecycle on that of the
    Customer will be based on the referential constraint between
    the physical Customer and Order tables.
    For example, if the constraint is "Cascade Delete", when
    the Customer entity is removed, the corresponding dependent object CustomerOrder will also be removed, and so on.
    That is, the CustomerOrder object will not only live as a
    part of Customer entity but will also die alongwith it.
    We call this as parent-child relationship in RDBMS.
    But again, this will work only for one-to-one or
    one-to-many relation between Customer and Order tables
    respectively.

    Hope I've made it clear now. I am anxiously awaiting
    your comments,

    Vaithi Nellaiappan
    Chicago
    nvaithi at hotmail dot com

  11. Hi Vaithi,

    You make complete sense here now that you have used the word "immutable"...

    I think I would design pretty much the way you suggested...
  12. EJB Design for complex Objects[ Go to top ]

    I have seen many articles/discussions using the parent as entity bean and child as dependent object but it is possible to some extent only if the child life cycle is only to be controlled by parent,for example
    customer and address, address can't be a row any more if the customer does not exist.
    At the same time designing database with one-to-many does not always have the above composition relationships,So the most of the times we need the child as well to be another entity bean and have a parent to hold the references of all its childs at one level.Again if that child has intern has one-to-may relations do the same thing and this time the first child(parent to the 2 nd step) will hold the references to it's intern childs.

    EJB 2.0 spec talks about the composition relation ships but there and that too for CMP and don't think they are talking any change in BMP.


    Any thougths?
    Thanks,
    ravi appala