我正在开发一个泽西岛的应用程序,我有很多资源.虽然这些资源的主要功能各不相同,但它们共享许多常用方法(如列表,读取,更新等).该应用程序在Google App Engine上运行,并使用Guice进行依赖注入.
我的第一种方法是拥有一个包含所有通用逻辑的通用AbstactResource,它分别由添加所需自定义方法的所有其他资源进行扩展.
public class AbstractResource示例资源看起来像：
public class TenantResource extends AbstractResource在这种情况下一切正常.当我添加一个更多抽象级别时会出现问题.假设我只想为某些资源存储历史记录和更改日志.我创建了另一个扩展AbstractResource的抽象类,名为AudiatableResource,它添加了所需的功能.
public abstract class AuditableResource如您所见,此案例中的type参数已更改(现在它扩展了AuditableModel).
新的具体资源将如下所示：
public class PropertyResource extends AuditableResource在这种情况下,一切仍然有效,但这次我在启动时收到很多警告信息：
WARNING: Return type T of method public T com.pkg.AbstractResource.get(java.lang.Long) is not resolvable to a concrete type
WARNING: Return type T of method public T com.pkg.AbstractResource.getNew() is not resolvable to a concrete type
WARNING: Return type com.pkg.data.ListPage我真的很想知道这种方法是否正确使用Jersey,如果我可以忽略这些消息.知道如何在有大量资源的情况下组织资源将会很有趣.
最佳答案
一种方法是将资源的定义与实现分开.
>拥有非常简单的资源类,定义您想要提供的不同服务.这样,您通过休息公开的API很容易找到并进行审核.不同的方法可能是实现类的委托
>在实现中实现资源的业务逻辑,您可能希望使用继承来考虑常见行为.
您在运行时获取这些消息的原因是,jersey使用有关资源中类型的运行时信息.在编译时擦除泛型类型信息,它无法获得泛型类方法的实际返回类型.如果为实现提供REST“外观”,则可以明确说明.
public class Facade {
private final PropertyResource propertyResource;
public Facade() {
propertyResource = new PropertyResource();
}
@GET
@Path("somepath")
public Tenant something() {
return propertyResource.something();
}
}
