EJB's and classic OO theory

Post #102,495 by bluke 5/19/03 2:38:21 AM Reply	EJB's and classic OO theory I have been reading up on EJB's and find that the whole EJB paradigm seems to go against classic OO theory. In classic OO theory, an Object contains both data and methods, for example an account object would contain both the account data (name, number, balance, interest rate, etc.) plus all the business logic related to an account, deposits, withdrawal, interest rate calculation, etc. EJB's seem to separate these into 2 separate objects, the Entity Bean which represents the data in the database, and the session bean which performs all the actions. Am I missing something here?
Post #102,524 by admin 5/19/03 8:46:32 AM Reply	Somewhat... The entity bean should have data and methods that directly work on that data. The session bean glues together entity beans with business logic that spans entity beans. Of course, they also tell you to use session beans and direct database logic as well. Entity beans are the most ridiculously complex, useless bit of junk I've seen in a while. Three interfaces for each bean! And they don't even relate to each other except through the xml bindings! It's garbage. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #102,706 by dmarker 5/20/03 4:03:32 AM Reply	As I understand it, the problem EJBs tried to solve was the need for server logic that could be isolated & thus made persistent if needed, but more importantly an EJB conformed to a standard design that supported getters setters and introspection. A EJB container being the mechanism for managing the persistence of the beans. AFAIR IBM's Hursley lab (of CICS fame) had a lot to do with the architecting & developement of EJB despite any dubious claims to the contrary from Sun. IBM were trying to bring some scalability to Java. As a former strong proponent of Java, I find it has become so damned complex and has so many non-OOT exceptions to the rule, that I wonder why the world missed ST. But such is life ... Doug Marker (Java was so digestable to former C programmers)
Post #102,712 by bluke 5/20/03 5:13:03 AM Reply	EJB Complexity Just the fact that you need a Home Interface for EJB's is ridiculous. It stems from the static typing and function calling orientation of Java. In a true message passing system these issues go away.
Post #103,043 by tuberculosis 5/21/03 11:11:06 PM Reply	The Home interface is the class interface Since Java doesn't have real class objects, they found they had to put the class hierarchy back via the home mechanism. Its quite lame. "Packed like lemmings into shiny metal boxes. Contestants in a suicidal race." - Synchronicity II - The Police
Post #102,875 by tablizer 5/20/03 10:39:07 PM Reply	Classic OO theory is fscked, modern OO is double fscked If you wrap all the data behind behavior, then it is harder to share data with other languages, applications, and tools. You end up reinventing a little mini database for each class: get, set, find, delete, save, dump, semaphore, sort, one-to-many object pointer lists (indexes), etc. Relational factors that commonality of interface/operations into a single spot. OO is so hell-bent on hiding implimentation that it violates OnceAndOnlyOnce (factoring) WRT interfaces. ________________ oop.ismad.com

Welcome to IWETHEY!