"composite entity" design pattern question


EJB programming & troubleshooting: "composite entity" design pattern question

  1. "composite entity" design pattern question (3 messages)

    i've read some interesting stuff about composite entity, wich i'd like to use in my app.
    However, i couldn't find material on "how choose the best object to form the composite entity". All the examples are made with a few especific tables/objects predetermined.
    In real life, in a big db, things are not that simple. I also read some material about the "object-relational impedance mismatch", but, anyway, I still need some advice on how to use the best groups of obects/tables to form the composite entities.
  2. It is hard to give general advice, because the "best" choices depend on so many different parameters.

    Here are the two rules of thumb I use:

    1) Where possible, I make a one-to-one match between tables and entities. This is the most straight-forward approach.

    2) Where the table data is too far removed from anything in the real world (which happens a lot with heavily normalized databases), I try to build objects that match logical business concepts. Factors I consider are:

    a) Would the entity make sense to a non-technical person?
    b) Will the queries used to populate entity data have reasonable performance?
    c) Will the entity data be likely to be used as a unit (e.g. to populate a single screen)?

    I admit that is vague, but it is the best I can do.
  3. In the first option, you`re not really using composite entity, are u?
    If u make a one-to-one mapping, you`re using ordinary beans (mapped one-to-one) to persist !?
  4. That's right. The first rule is basically: "avoid composite entities if I can".

    The other rules are: "if I can't avoid composite entities, here is what I think about".