应用状态判定：应置于表现层还是业务层？

Great question—this is a super common pain point when building layered Java EE apps, especially when you’re planning to add multiple presentation layers down the line. Let’s break this down with your specific tech stack (JAX-RS, stateless EJBs, JPA) in mind.

App State Determination: Where to Put It? #

The golden rule here is: core business state logic belongs in the business layer (stateless EJBs), while the presentation layer (JAX-RS) only adapts and exposes that state to the client.

• Why? Your business layer should be the single source of truth for all business rules. If you put state checks (like "is this order eligible for a refund?" or "does this user have permission to edit this resource?") in JAX-RS, you’ll have to duplicate that logic when you add other presentation layers (e.g., a desktop app, WebSocket endpoint) later. That’s a violation of the DRY principle and a maintenance nightmare.
• Example: Your stateless EJB might have a method like boolean canRefundOrder(Long orderId) that encapsulates all the rules (order is less than 30 days old, hasn’t been refunded yet, etc.). The JAX-RS layer calls this method, then translates the result into something REST-friendly—like adding a refundable: true field in the JSON response, or returning a 403 Forbidden if the client tries to call the refund endpoint when it’s not allowed.
• Exception: Presentation-layer-specific state checks (like validating HTTP request headers, checking if query parameters are in the right format) belong in JAX-RS. Use things like @Valid annotations or ContainerRequestFilter to handle these without cluttering the business layer.

Response Actions: Who Decides What to Expose? #

This splits into two distinct responsibilities:

1. Business Action Availability (Allowed Operations) #

This is 100% the business layer’s job. Your EJBs should return metadata about which actions are possible for a given resource. For example, instead of just returning an Order entity, return a business object like OrderWithActions that includes:

• The core order data
• A set of allowed actions (e.g., {"cancel", "refund", "track"})
• Boolean flags like isCancelable or isRefundable

This way, the business layer controls what’s possible, and the presentation layer just decides how to present those options to the client.

2. Presentation-Specific Action Formatting #

This is the presentation layer’s responsibility. For your JAX-RS REST API, that means turning those allowed actions into HATEOAS links (using JAX-RS’s Link class), mapping them to HTTP methods (PUT for update, DELETE for cancel), or structuring the JSON response to match REST conventions. If you later add a desktop app, that layer might turn those same allowed actions into clickable buttons instead of links—no changes needed in the business layer.

Practical Tips for Your Tech Stack #

Stateless EJB Layer #

• Focus on encapsulating business rules: Write methods that return business objects (not raw JPA entities) containing state and action metadata.
• Keep EJBs stateless (as you’re already doing) to ensure scalability—pass all necessary context (like user IDs, order IDs) as method parameters.

JAX-RS Layer #

• Use DTOs (Data Transfer Objects) to convert business objects into REST-friendly responses. For example, map OrderWithActions to OrderResource which includes HATEOAS links.
• Handle HTTP status code mapping here: If the business layer says an action isn’t allowed, return the appropriate status code (403 Forbidden, 409 Conflict) instead of just a generic error message.
• Avoid adding any business logic here—your JAX-RS endpoints should be thin adapters between the client and the business layer.

JPA Layer #

• Stick to its single responsibility: Data persistence. Don’t add business rules or state checks in entity classes or repositories. Let the EJBs handle that.

Why This Design Works #

• Scalability: When you add new presentation layers later, you don’t have to rewrite business logic—just adapt the existing business layer responses to the new client’s needs.
• Maintainability: All business rules live in one place. If you need to update the refund policy, you only change the EJB, not every presentation layer.
• Testability: You can unit test your business layer logic independently (using JUnit for EJBs) without needing to spin up a web server or mock HTTP requests.

内容的提问来源于stack exchange，提问作者Paul H