我正在尝试找出我的 API 项目架构的选项。

我想使用 JAX-RS 1.0 版创建一个 API。此 API 使用来自更大、更旧且更复杂的应用程序的远程 EJB (EJB 3.0)。我正在使用 Java 6。

到目前为止，我可以做到这一点并且可以正常工作。但我对解决方案不满意。查看我的包裹配置。我的担忧在代码后描述:

/api/
    /com.organization.api.v1.rs -> Rest Services with the JAX-RS annotations
    /com.organization.api.v1.services -> Service classes used by Rest Services. Basically, they only have the logic to transform the DTOs objects from Remote EJBs in JSON. This is separated by API version, because the JSON can be different in each version.
    /com.organization.api.v1.vo -> View Objects returned by the Rest Services. They will be transformed in JSON using Gson.
    /com.organization.api.services -> Service classes used by versioned Services. 
        Here we have the lookup for Remote EJBs and some API logic, like validations. This services can be used by any versioned of each Service.

com.organization.api.v1.rs.UserV1RS 示例:

@Path("/v1/user/")
public class UserV1RS {

  @GET
  public UserV1VO getUsername() {
     UserV1VO userVO = ServiceLocator.get(UserV1Service.class).getUsername();
     return userVO;
  }

}

com.organization.api.v1.services.UserV1Service 示例:

public class UserV1Service extends UserService {

  public UserV1VO getUsername() {
    UserDTO userDTO = getUserName(); // method from UserService
    return new UserV1VO(userDTO.getName);
  }

}

com.organization.api.services.UserService 示例:

public class UserService {

  public UserDTO getUsername() {
    UserDTO userDTO = RemoteEJBLocator.lookup(UserRemote.JNDI_REMOTE_NAME).getUser();
    return userDTO;
  }

}

我的项目的一些要求:

• API 的版本有:v1、v2 等。
• 同一版本服务的不同 API 版本可以共享代码:UserV1Service 和 UserV2Service 使用 UserService。
• 不同版本服务的不同 API 版本可以共享代码:UserV1Service 和 OrderV2Service 使用 AnotherService。
• 每个版本都有自己的 View 对象(UserV1VO 而不是 UserVO)。

上面的代码让我感到困惑的是:

1. 这个 ServiceLocator 类对我来说不是一个好方法。此类使用旧库中的遗留代码，我对此类的工作原理有很多疑问。 ServiceLocator 的使用方式对我来说也很奇怪，这个策略是not good to mock the services for my unit tests .我想创建一个新的 ServiceLocator 或使用一些依赖注入(inject)策略(或其他更好的方法)。
2. UserService 类不打算由另一个“外部”服务使用，例如 OrderService。它仅适用于 UserVxService。但在未来，也许 OrderService 想使用来自 UserService 的一些代码......
3. 即使我忽略了最后一个问题，使用 ServiceLocator 我也需要在我的代码中做很多查找。创建循环依赖项(serviceOne 查找 serviceTwo，查找 serviceThree，查找 serviceOne)的机会非常高。
4. 在这种方法中，VO(如 UserV1VO)可以用于我的未版本化服务 (com.organization.api.services)，但这不可能发生。好的架构不允许出现不允许的情况。我想创建一个新项目，例如 api-services 并将 com.organization.api.services 放在那里以避免这种情况。这是一个好的解决方案吗？

那么...想法？

最佳答案

我看到的几件事:

• UserService 理想情况下应该基于接口(interface)。它们似乎有类似的契约，但唯一的区别是它们的来源(RemoteEJB、LocalServiceLocator)。这些应该是返回 DTO

• UserV1Service extends UserService 应该不使用继承，而应该支持组合。想想您需要为同一服务的 v2 做什么。根据您的示例，您将获得 UserV2Service extends UserService。这并不理想，尤其是当您最终在基类中使用特定于一个版本的抽象方法时。然后突然之间，其他版本化服务需要满足这一要求。

对于ServiceLocator

• 在您的情况下，您最好使用像 Spring 或 CDI 这样的依赖注入(inject)框架。如果您的项目是新项目，这仅适用于您自己的代码。

• 对于难以进行单元测试的那些，您可以将 RemoteEJB 调用包装到它自己的接口(interface)中，这样可以更轻松地进行模拟。 RemoteEJB 的测试将成为该项目的集成测试。

The UserService class is not intended to be used by another "external" service, like OrderService. It's only for the UserVxService. But in the future, maybe OrderService would like to use some code from UserService

同层的Services互相通信是没有问题的。

In this approach, the VOs, like UserV1VO, could be used in my unversioned services (com.organization.api.services), but this cannot happen. A good architecture don't allow something that is not allowed. I have the idea to create a new project, like api-services and put the com.organization.api.services there to avoid this. Is this a good solution?

仅仅因为你“可以”做某事并不意味着你应该做。虽然将层分离到它自己的项目中似乎是个好主意；实际上，没有什么能阻止开发人员在该项目中重新创建相同的类，或者在类路径中包含 jar 并使用相同的类。我并不是说拆分它是错误的，只是应该出于正确的原因而不是“如果场景会怎样”来拆分它。

关于java - 使用 : JAX-RS API, ServiceLocator 和远程 EJB 组织我的项目的选项，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39283235/