What you can do is break up your one single interface in n interfaces, but
all sharing one impl bean with n number of homes.
This way whenever your client needs specific functionality, he has to call
that home. This way you can group similar functions in one interface, and
provide different interface for same impl depending on home.
But this way, your client has to decide when to call which home, for a
specific function.
punit
>Hi all,
>
>I have a application in which a single Session Bean is offering services
>to the client, which is a Java applet. This bean, in other words, is
>acting as a container bean.
>Since I am in the very intial stage of my project development, it
>contains just 15 methods in its remote interface. But in the later
>stage, Remote Interface could be a very large interface with 150 to 200
>methods. I am not sure if I like the idea of having such a big
>interface. But I also want to avoid having a single method in the remote
>interface and its implementation with IF ..Else structure to find out
>the action to be taken.
>Could you please suggest a way of getting around this design problem ?
>
>Manisha
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
>
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
