EJB 2 entity beans vs real life


General J2EE: EJB 2 entity beans vs real life

  1. EJB 2 entity beans vs real life (2 messages)

    Finally IBM has caught up and we have EJB2 with our early release of Webs*#[email protected] 5. Basic development speed will be increased with EJB 2 because it allows developers to use fine-grained entity beans. That's great.

    After being involved with developing a large number of EJB projects as well as pre-J2EE projects, the two most important points for medium to large projects using entity beans are
    (1) Encapsulate the data layer away from the use-cases/business logic by using session beans. Then it does not matter how the session beans interact with the database
    (2) Make sure developers have very strong database skills

    Unfortunately Java developers think that J2EE means they don't need very stong (SQL/relational) db skills. Articles typically encourage this by concentrating on how J2EE will do it all for them. Many patterns also encourage this. Well nothing great ever came from using patterns.

    (1) I'd like to see developers gaining greater database skills as they did ten years ago. Nothing can replace good db skills. For many companies, this is where their money is.

    (2) I'd like to see less emphasis on the App Server's ability to do the easy stuff easily and more on how good database design will be more centered around data retrieval and interoperability than whether an entity bean can give you an n:m relationship. It is only journal writers that get excited about doing the easy stuff easily and sadly this misguides neophyte developers.

    (3) I'd like to see a stop to all patterns. Will people please stop centering their thoughts on mediocrity? Christopher Alexander knew not to do it, so why are you?

    (Stephen dot Graham at combined dot com dot au)

    Threaded Messages (2)

  2. EJB 2 entity beans vs real life[ Go to top ]

    I have been frequently hearing about it lately and I am sick of this "database skills" thing. Relational DB design does not require any skills; actually, there is nothing more to it than normalizing for flexibility or denormalizing for performance. Any "skills" were needed prior to Date's book.

    J2EE developers (or developers with any object oriented arsenal, for that matter) don't need database skills. They need a good understanding of the object oriented paradigm and the object oriented analysis and design processes.

    When done correctly, entities and their relationships in the object oriented design always map to a fully normalized database ER. Luck? Coincidence?

    Tweaking the object design with the relational model in mind is a dumb thing to do. Why bother with lengthy object oriented analysis and design if you are going to throw it out the window? Write the whole system using stored procedures and GUI forms or 4th generation languages. After all, most of the world still runs RPG, PowerBuilder, Oracle Forms and VB in front of some kind of SQL; they can't be wrong.

    Regarding design patterns, I'd like to see a stop to people calling a design a "pattern" just because they can put it down in GOF format. I have voiced this opinion many times elsewhere in these forums.
  3. EJB 2 entity beans vs real life[ Go to top ]

    Here here!! OOA/D is much more important and there isn't anything complicated about Relational databases.

    There are much more important things to learn in J2EE:
    * OOA/D
    * Transactions
    * Concurrency - Use case over mulitple transactions
    * Caching - how to reduce database access
    * Clustering
    * Security
    * Transparent failover
    * Bulk reading. eg. listing of product catalog