I'm finding it difficult to understand where we should use entity beans. Just reading 'Complex Persistence' by Scott and he says 'We made Address an entity bean because we want to be able to easily manipulate it and because it is a major business concept for our system'. Can we so casually create entity beans because we want to easily manipulate something? I'm not arguing if Address is an important business concept or not as I don't know which system he's talking about.
Entity bean data is synchronized with the data in database. So there is an overhead. And they have all those overheads associated with EJBs.
Every user will have an address and 'generally' he alone changes his address. Then why do we need to synchronize it with database? Typically, address is changed very rarely. Why don't we get it as a value object and store it in HttpSession/Client? If it's changed, we can update the database and the value in HttpSession. I was taken aback when one WebSphere consultant said that they are storing HttpSession data in database, but that's much more rational and cost effective solution to manage such data than modeling that as entity bean, I guess. It's a question of having 10000 entity beans on EJB tier or 10000 value objects in HttpSession. I'll vote for some lightweight management in HttpSession.
PetStore also uses entity bean for Address. I really can not see the rationale behind wasting resources for such a trivial(for most of the applications I assume) data.
One argument may be Address may be changed by some other module, so we need to maintain the latest data. Then it may have to be modeled as entity bean. I thought we should model something as an entity bean only if 'More than one module may change the same data and so we need to synchronize the data in the object with database.' Right now as we don't have any other mechanism in J2EE to synchronize with database other than entity beans, we may consider entity beans. If we have something like Toplink, we need not use them at all.
Don't get me wrong, I do respect people like Scott, but it reminds me of my OO teacher saying 'Object has has some properties/data and behavior/methods. Data should be encapsulated, but an object should be able to tell you it's properties when asked. So getName(), getAge() blah, blah...'.
Only after I started working in the industry and in large projects I'm able to really appreciate the significance of OO. (If used properly)It helps to manage the complexity better and make the code more readable. So it reduces the cost. That's all about OO.
I think the best way to understand these concepts is to solve a problem that is suitable for that concept. I'm not sure if Address is one for entity beans.
Please enlighten me. 'Address' and 'Entity Bean' are really troubling me :-).
Thanks and regards,
I'm not convinced you need this level of analysis. EJB is an approach which you embrace or not. If not, then I think there is an argument for never using it. Its just adding network latency and complexity to a trivial problem (ie database to browser) - Flash does this pretty well, and could just inherit the earth.
If you embrace EJB then the reasoning may well be
a) You accept that scaleability and robustness are offered by app servers (databases do as well but ignore that)
b) You want to learn EJB and do some implementation.
c) You want to position your project so you can easily ride the EJB power curve (!). i.e. when EJB actually starts being useful you are in a position to easily gain from it. Some of the JMS bean stuff is starting to look as if its useful.
So once you have made your selection then the worry over when to use it does drop away. Where-ever possible you use EJB's. It's that simple.
So the address problem changes from should I do it as an EJB, to I can use EJB so I will.
I'm convinced that EJB's are useful. My question is about entity beans. I don't have any doubts about the utility of session beans. My problem stems from the feeling that Sun seems to be misleading people like me with entity beans. Basically these are the problems...
1.It would be great if I don't have to write all those SQL scripts.
2.It would be great if the changes I make to the object in memory is magically reflected in database.
3.It would be great if multiple threads can access that object without leading to any data corruption.
4.All the above should be fast, and should cost me less $ to buy and should use less resources at runtime.
That's all I need I guess. Other problems can be solved with session beans. Sun seems to be saying entity beans is the only solution. Is it true?
Just because I want to listen to music while I travel, I won't buy a car. I'll buy a little radio and headphones. Just because I prefer air-conditioning while I travel, I won't buy a car. I'll go in a public bus(at least in Singapore).
Just because I don't want to wait for a public bus, I won't buy a car. I'll buy a motor cycle.
If I'm so rich that cost of a car is negligible, I'll buy a car.
I'm not so rich yet and so want to know the costs of using entity beans and alternatives to that. Thanks in advance to someone who can clear up this mess.
The same troubles my friend... As I can understand that situation - the Sun depicts EJB components as highly reusable and independable. So, if we use Session Beans instead of Entity ones (currently I mean CMP ones) - we need to code a lot of SQL and we become dependent from our database vendors. As for BMP (this guys from Sun recomend to use CMP if it's possible, but they tell after that using optimized BMP beans we could achieve better speeds, but we will lose our dependency from database vendor here - it will a lot of work for EJB programmers, but otherwise there will be a little work for EJB deployers - so you choose).
If you compare BMP Entities and Sessions - there is a small issue. Yes, it will be cheaper and faster for you to use Sessions instead of Entites, BUT: you will need to code your transaction layers yourself (trying to reinvent wheel?) instead of using AppServer's routines. That's the main point. If you do not need transactional output - use Session beans with DAO (BTW, Sun guys discuss that pattern (don't remember name - direct access or so on) in their J2EE blueprints), otherwise use Enitites or CODE TRANSACTIONS yourself...
May be there are more issues exist, but I can see only this ones from my point... And I am continuing to use entities - I just got used to them, and I like CMP!!!!!
my observation is
If you are going to Use a record again and again.You have have it in an entity bean which is wrapped by a
say stateful session bean. So it is easy in the part of the programmer to deal database records as an object.
But if it is just a record which i need to just say read, There is no point in having an entity bean.
when will container passivate the bean. How long that object will be in memory if i am having say
100 of tables and 100 enity beans are representing it. Getting a bit confused there.
There is also another aspect of using entity beans - what does it represent ? Is it a 1:1 mapping of a tabel in the database or is it a logical representation of a collection of tables ?
Say that you have designed your database in such a way that info regarding a person (identified by personID - whatever that is) is split up in several tabels all with just the personID as primary key. You have done this because of some reason ie. very many columns not used at the same time, priviligate to update certain columns or whatever.
Should there be one EB for all those tables or one for each ?
Should there be a "master entity bean" that manages the other beans ?
What are the criterias for choosing strategy ?
Suppose there are more tables where personID is a part of the primary key - what happens with those ? Individual EB's or part of the big EB ?
Finally - if you want to deliver a complex set of data from many tables (5-10) to the user as a list to choose from, does it make sense to use several EB's or do you just make a specialized session bean with JDBC ? Specialized because I don't want the SQL in the first session bean.