1 2 Previous Next 22 Replies Latest reply: May 22, 2002 11:46 AM by Ian Hunter RSS

Questionable trends regarding Entity Beans ...

Peter Sojan Newbie

Recently one can observe diferrent trends which cast some doubt on the intention of Entity Beans:

- First, developers now tend to use Data-Access-Objects (DAOs) for their low-level database access. These DAOs exist outside the entity bean and isolate database-specific access logic. Originally data-access happend in the Entity Bean itself.
- Secondly, nowadays it´s suggested to create Data-Objects (DOs) which hold an entire entity object which, once filled with data, can be conveniently transferred between the different tiers. So instead the Entity Bean we now have another "Container" with similar functionality as for which Entity Beans where originally planned.
- Another trend proposes the use of Session Facades to shield Entity Beans from Remote Access. This is now possible since DOs can be tunneled through session beans beck and forth to/from the clients.
- Finally one can observe the trend that more and more data-access happens in session beans. This is often used for doing relationships between Entities. But since we have now DAOs and DOs, one can handle those relationships directly without even touching Entity Beans (often used for [bulk]queries and for performance reasons)

Did you notice something? At the end of this process we moved nearly ally functionality out of the Entity Bean into DAOs, DOs, and Session Beans.

My question: By applying all these patterns (which are also proposed by SUN blueprints), what are Entity Beans finally good for? What is the "Use-Case" which is left over for an Entity Bean?

Any comments appreciated.
Peter

  • 1. Re: Questionable trends regarding Entity Beans ...
    Peter Sojan Newbie

    Uh, sorry for my spelling mistakes. I would not recommend to post anywhere when being awake for 24h+ ...

    hey there's a spell check button :-)

  • 2. Re: Questionable trends regarding Entity Beans ...
    F Zemen Newbie

    I think entity beans are very much misunderstood by many developers in decision making roles.

    Whether BMP or CMP, people sometimes forget that the entity bean is not doing anything much different than the DAO, the session bean w/JDBC etc. The are scared of CMR (and frankly, there are times to use it and times not to) as if CMR didn't do things their own JDBC code do.

    There are very real reasons for some products/deployments not to use entity beans. Sometimes other patterns/technologies are better, but often in such cases the best pattern would be a series of stored procedures anyways.

    I am convinced from working on three projects and four products that people just don't get entity beans and that hype and outdated patterns and so called "best practices" articles are responsibly for the trends you mention.

  • 3. Re: Questionable trends regarding Entity Beans ...
    Vincent Harcq Newbie

    > Recently one can observe diferrent trends which cast
    > some doubt on the intention of Entity Beans:
    >
    > - First, developers now tend to use
    > Data-Access-Objects (DAOs) for their low-level
    > database access. These DAOs exist outside the entity
    > bean and isolate database-specific access logic.
    > Originally data-access happend in the Entity Bean
    > itself.

    DAO is only needed when you write BMP. Most of work on database should better be handled by CMP. Then if at one occasion you need specific access to something other than JDBC, then BMP have its place.
    BTW, Coarse Grained entity patterns sucks. It was badly introduced when local interfaces were not in the spec but even without that most containers handles relationships between entity beans like a charm. And now CMP 2 is there it is even more simple.

    > - Secondly, nowadays it´s suggested to create
    > Data-Objects (DOs) which hold an entire entity object
    > which, once filled with data, can be conveniently
    > transferred between the different tiers. So instead
    > the Entity Bean we now have another "Container" with
    > similar functionality as for which Entity Beans where
    > originally planned.

    DO are there to represent an entity to "client" (or exteranl world whatever name you gave to what does not work in a short transaction). Most of the time this client is the web. You have a long transaction there (click, think, click think,...). Then you give the state of your entity to the client like that. You can also send back changes to this state to the EJB container.
    DO should not be used inside EJB when calling each others.

    > - Another trend proposes the use of Session Facades
    > to shield Entity Beans from Remote Access. This is
    > now possible since DOs can be tunneled through
    > session beans beck and forth to/from the clients.

    You have data and you have process (business case, ...). You build your process with session beans. These one will need some data and so call multiple entity beans or other service.

    > - Finally one can observe the trend that more and
    > more data-access happens in session beans. This is
    > often used for doing relationships between Entities.
    > But since we have now DAOs and DOs, one can handle
    > those relationships directly without even touching
    > Entity Beans (often used for [bulk]queries and for
    > performance reasons)

    This is the only place where I will be with you and where entity beans miss something today. Heavy read to represent data to the "client" gives poor performance because Locking is always involved. That is why most of people do that using JDBC.

    > Did you notice something? At the end of this process
    > we moved nearly ally functionality out of the Entity
    > Bean into DAOs, DOs, and Session Beans.
    >
    > My question: By applying all these patterns (which
    > are also proposed by SUN blueprints), what are Entity
    > Beans finally good for? What is the "Use-Case" which
    > is left over for an Entity Bean?

    Entity bean is one possible representation of "Business Object" (a Customer, an Order, a Account transaction, ...)
    Session beans is one possible representation of "Business API"

    You externalize transaction, integrity and security completely using them. For these reasons session/entity bean is better than any alternative where you have to handle these yourselves.

    A final note on Patterns. Most of them are not pattern in OO sense but tricks to make the work you have to do running faster. Don't be overloaded by these patterns, review your thinking by first understanding the benefits by a high level approach, then come to the patterns.
    Personnaly I come to EJB through Gemstone i Commerce Guide. I am not sure it is still available but it put the right ideas in a 20 pages document.

    I do not pretend to be accurate in all what I am saying but only speak after one year of intensive work on EJB.

    ENTITY BEAN IS BEAUTIFUL

  • 4. Re: Questionable trends regarding Entity Beans ...
    Ignacio Newbie

    Hey, que alguien me diga como poner mi texto en morado! :D

    Only to be added here: You use Data Objects (well, I knew them as Value Objects) because there is no way to call getPk() and getName() and getAge() on an Entity bean without triggering a transaction for each call.

    When I see the work that CMP has made for me my legs tremble.

  • 5. Re: Questionable trends regarding Entity Beans ...
    IPOz Newbie

    I like EntityBean for its OO thoughts.However i feel it is not convenient using Collection to package data.
    I have tried to use CachedRowSet to package data in finder methods but failed to deploy.

    What i want to know is whether or not i can use other ways such as CachedRowSet or XML to package data in finder/select methods of EntityBean?


    Best Regards!

  • 6. Re: Questionable trends regarding Entity Beans ...
    Craig Johannsen Newbie

    Yo no se. Pero es possible poner la palabra "code" antes de su texto adjunto en braketos [ code ] y la palabra "/code" despues de su texto, tambien adjunto en braketos como "[ /code ]", pero omita space carácter. Por ejemplo:

    public static void main( String args[] ) {
     if (args[1].equals("debug")) {
     System.out.println("Debugging...");
     }
    }
    


  • 7. Re: Questionable trends regarding Entity Beans ...
    Ulrich Romahn Newbie

    How funny, this last reply :)

  • 8. Re: Questionable trends regarding Entity Beans ...
    sundar Newbie

    I totally agree with the issues you have mentioned about using entities.Sun has really moved away all the importance it had given to entity beans.From my prj experiences..I have understood that Entities are no good.Taking a decision about when to go for entities is itself has become a tough decision (eventhough reading the blahblahblah documents).The plain and simple approach to any web-applications(as I hope) is to limit oneself using struts(as web framework),session beans and DAO's which calls stored procedures.This approach keep our project neat and easy to think about design.
    Secondly,handling all the application server related configurations that sticks with entities is again a trouble.The entities actually makes us to have one more level of database maintenance.
    I have seen most design guidelines refer using entities.But somehow they are avoiding the pitfalls faced in real life (project !) knowingly or unknowingly.

    The bottom-line is Entities are bad, Avoid It.

  • 9. Re: Questionable trends regarding Entity Beans ...
    IPOz Newbie

    I agree with you . In our project we use the pattern below :

    jsp/servlet -> javaBean --->[businee stateless session bean->data object stateless session bean] -> RDBMS

    As you see we use two layers of session bean:Business Object(BO) + Data Object(DO).At the beginning we only developed DO which can be used by the javaBean.Each DO is responsible for manipulating one table in RDBMS.If the business is complicate and relative to more than one DO then we can build a BO to encapsulate the business logic.

    Although the rowset is not powerful enough we still use it to transfer data between different layers.We hope there is a standard way to package data(such as XML).Then third party can develop some data aware controls to manipulate data in a standard way.
    If you know Delphi you should know what i mean:
    In delphi the DBGrid,DBEdit etc. is very convenient for a programmer to develop a UI.The key is that the TDataSet and its derives are standard so that there exists so many third party controls in the world.

    In a word i suggest you donot use entity bean !!!


    Regard

  • 10. Re: Questionable trends regarding Entity Beans ...
    David Jencks Master

    A couple of minor comments.

    You only trigger a _new_ transaction on an entity bean when calling getpK, getThis, getThat if you call it outside of a transaction context. This normally means you haven't designed the transactions in your business process, so your application is doomed anyway, to overstate the case a bit.

    Using session beans instead of entities loses any possibility of transparently caching data, configuring commit options, persistence manager independence, etc etc, and promotes confusion between the layers responsible for data access and business process.

  • 11. Re: Questionable trends regarding Entity Beans ...
    J. Wolfgang Kaltz Novice

    I think an important issue is whether you are trying to integrate with a legacy system, or are designing a new system from scratch (including the database).

    If you are integrating a legacy system, which is probably what most web applications do, entity beans probably do more harm than good, because you would likely end up duplicating something which already exists in the backend in some form. If you have a completely new system, then you need something new handling persistence et al., so then entity beans would be a candidate.

  • 12. Re: Questionable trends regarding Entity Beans ...
    Adrian Newbie

    Forget about 200 pages EJB design patterns that can get outdated by the time you buy the book.

    1. Use Session EJB for business logic and to read-only persistent business objects
    2. Use the Entity EJB to create or update the persistent business objects

    And don’t forget that even in 80% of the cases the Entity EJB are working with a RDBMS they might persist in other forms: LDAP, mainframe, …

    Adrian

  • 13. How to instantiate the entity bean in such a situation
    IPOz Newbie

    Hi,friends
    Maybe it is a foolish question but i really want to make it clear.suppose we have a table employee as below:
    create table employee (
    emp_id char(10) not null primary key,
    emp_name varchar(20) not null,
    ....
    )
    And we have developed an entity bean called EmployeeBean.
    Now if the clients,such as jsp or session bean,want to get records whose emp_name include word "john",then we need to write a finder method as findByEmpName(...).However the clients must instantiate a EmployeeBean before calling this finder method. What i want to know is how the clients instantiate the entity bean ?
    The create(...) methods can NOT be used to do it because the records are already in employee table.How about the findByPrimaryKey(...) method ? It still cannot because the clients donot know the primary key value.

    Please help me make it clear.


    Thanks in advance

  • 14. Re: How to instantiate the entity bean in such a situation
    IPOz Newbie

    Sorry for my poor English !

    Of course i know the STANDARD finder method can be called before instantiating the real entity bean as below:
    ...
    Object = initilalContext.lookup("the entity bean jndi name");
    entityHome = (entityHome)PortableRemoteOnject.narrow(...);
    entityHome.findByxxxx(...);
    ...
    However those standard finder methods can only return Collection type data set :(
    If the finder method is as below:
    public RowSet findByEmpName(...) then how can i call it before instantiating the entity bean ?

    Hope i express it clearly :)

1 2 Previous Next