Hello,

I am debating using the Command pattern as my primary strategy for
implementing my enterprise app business logic. The general idea is to
have only a few types of abstract commands (with various types of
transactional integrity) and implement each use case as a command. The
result of my design will be a very small set of stateless session beans
with an execute() interface. No entity beans (will use Hibernate) and
may very well eventually implement a Message bean interface with a
similar executeAsynchronously() type method, if eventually necessary.

I guess the popular alternative (or, more correctly, the norm) is to
implement session facades for this.

However, I am attracted to the Command pattern because of its
simplicity, it's rapid application development angle, its
disconnected-ness from EJB (e.g., a modification to a command does not
mean touching any EJB at all, just the command class), and the ability
for implementing cross-cutting features (such as transactions or
security, although I also plan to use an AOP solution at the POJO
level).  At the same time, it works as a delegate of an EJB, so it's
accessible for all kinds of network clients.

I am also familiar with it's drawbacks (e.g., maintainability for large
numbers of commands, per the literature, such as the Marinescu 2002 EJB
Patterns book).

So, very few stateless session beans -- mainly there for remote client
acceessibility and the ability to leverage application-level
transactions if needed.

Nevertheless, I have never tried the command pattern approach and was
curious if others had feedback or case studies.

Best regards --