企业级Bean命名规范咨询：@ConversationScoped与@RequestScoped Bean命名

Great question—naming consistency is critical for keeping your team's codebase maintainable, especially when working with different CDI scopes. Let's walk through practical, convention-aligned options that will play nicely with your existing *View naming for @ConversationScoped beans.

First, let's validate your existing approach: using View for @ConversationScoped beans makes perfect sense, since this scope is typically tied to long-lived user interactions (like multi-step wizards or tabbed workflows where state needs to persist across multiple requests).

For @RequestScoped beans—short-lived, tied to a single HTTP request—here are the most common, team-friendly naming patterns to consider:

• *Request: The most explicit option. Names like ClientRequest or ContractRequest immediately signal the bean's scope and purpose. This is ideal if the bean primarily handles request parameters, data binding for a single submit, or lightweight logic tied to one-off user actions.
• *Action: Perfect if your @RequestScoped beans are focused on executing business logic triggered by a single request (e.g., form submissions, button clicks). ClientAction or ContractAction clearly communicates that this bean is responsible for handling a discrete, one-time action.
• *Handler: A slightly more verbose alternative to Action, suited if the bean's main job is processing request input or coordinating downstream services for a single request (e.g., ClientRequestHandler). Use this if your team prefers more descriptive naming.
• *Controller: Use this only if your project doesn't already have MVC-style controllers (like JSF managed beans or Spring MVC controllers) that might cause confusion. If clear, ClientController works for beans that mediate between the view and backend for a single request.

Key Recommendation #

Pick one pattern and stick with it across your team. For example, if you go with *Request, all @RequestScoped beans in the view package should follow that suffix—this eliminates ambiguity and keeps your codebase consistent.

If you're unsure, start with *Request or *Action based on the bean's primary role: use Request for data-focused beans, Action for logic-focused ones.

内容的提问来源于stack exchange，提问作者Igor Gorbunov