When to use EJB?

[Enrique]

What are the most important things to consider when determining if EJB
is right for my project?

Thank you.

 

[Abdullah Kauchali]

is right for my project?

I would determine, primarily, on the basis of this:

if you want your application to participate in *distributed* transactions
with other applications and their databases, use EJB - that's its job.
(Corollary: If all your transactional requirements are local ie. they
affect one database only or the transactions do not span multiple databases,
then I would say do not use EJB.)

That being said, I would certainly earmark some "special" components to be
both available to participate in local transactions as well as distributed
(EJB) transactions. This would be a pretty good insurance that other
applications in the future can invoke functionality from your API's and
still participate in transactions.

So the upshot: transactions. (But there are other reasons. I would be
content with the transactions argument, that's all.)

Regards

Abdullah

 

[Jean-Marc Vanel]

Le 04/01/2004 07:24 AM, Enrique a écrit :

What are the most important things to consider when determining if EJB
is right for my project?

Besides what Abdullah sais, there is another big reason for using EJB.
If your entreprise has an LDAP user directory or similar, you can leverage on
that with EJB. You can code your application classes without ever programming
things like :

if ( user.role == MANAGER ) {
method1();
}

because :
- the EJB container keeps track of the real user who is executing
- on deployment the administrators can associate a role with a list of methods
allowed

 

[Collin VanDyck]

What are the most important things to consider when determining if EJB
is right for my project?

Thank you.

I find that the database abstraction (entity EJBs) is almost reason enough
to use EJBs if you are going to be doing lots of complicated relational db
work. That coupled with the transactional model it supplies is very
powerful.

Though, with this justification one could easily overcomplicate what would
be a simple project.

CV

 

[James]

If you are writing a distributed application or not and if you are holding
state or not for starters. No less important is there a need for the added
complexity - unless you opt for a MessageDrivenBean which is a useful
asynchronous messenger. State can often be held in the session if the
amount is not overwhelming so Stateful session beans may or may not give you
a boost. I'd say chuck the Entity Beans - They are improving but they
probably are the biggest friend .net ever had.