John,
Our best practices team has documented some patterns in this area. We tend
to group Session Beans methods (services) by subject, sub-system or
specialized service.
* Domain Subjects *
For example, assume we are doing order processing, and we have a group of
domain objects (some entity beans and some dependent objects) that represent
Orders. We would have a Session Bean called OrderManagementService that
would provide services to support the use cases around orders.
* Sub-System *
You might find that you have groups of services that cut across domain
subjects. Examples include Reporting, Security, WorkFlow... We create
Session Beans that provide groups of related services and name them
accordingly, e.g. ReportingService.
* Specialized single function service *
You may find that you have certain services that are singular and
specialized such as UID/OID generation services. We create a Session Bean
that provides the service and name it accordingly, e.g.
OIDGenerationService.
<vendor>
Examples of these patterns are provided in the Developer's Guide that we are
about to publish. YOu can sign up for a copy of this at our WEB site.
</vendor>
Regards,
-Chris.
http://www.gemstone.com/
> -----Original Message-----
> From: John Kidd [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, January 18, 2000 9:56 AM
> To: [EMAIL PROTECTED]
> Subject: Bean Granularity
>
>
> How granular do you make your Session beans? One method per? Two? Three?
> Is there a rule of thumb?
===========================================================================
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".
