如何解决RequestFactory理论:为什么经常调用Locator <>find?
成对的getId
和find
结尾是的默认实现Locator#isLive
:如果通过其ID查找到对象返回非空值,则假定该对象处于 活动状态
(即数据存储中仍存在)。
RF会在构造响应时检查EntityProxy
在请求/响应期间看到的每个对象的 活跃性
,以告知客户端实体何时被删除(在客户端,它随后会EntityProxyChange
通过DELETE
write操作 触发一个事件。
当然你也可以超越的isLive
你Locator
用更优化的实现,如果你能提供一个。
解决方法
我是RequestFactory的新手,但是在ThomasBroyer的慷慨帮助下,并且在查看了下面的文档后,它变得越来越好:)
但是请您解释一下为什么Locator<>.find()
经常被不必要地打扰(我认为)?
在我的示例项目中,我有两个实体“组织”和“人”来维护父子关系。当我获取组织时,Objectify会 自动
获取子Person。另外,我在服务层中创建了两个方法findOrganizationById
,分别saveOrganization
用于加载和持久化对象。
现在考虑两种情况:
当我findOrganizationById
在客户端中致电时,服务器端会发生以下呼叫:
OrderDao.findOrganizationById(1)
PojoLocator.getId(Key<?>(Organization(1)))
PojoLocator.getId(Key<?>(Organization(1)/Person(2)))
PojoLocator.getId(Key<?>(Organization(1)))
PojoLocator.find(Key<?>(Organization(1)))
PojoLocator.getId(Key<?>(Organization(1)/Person(2)))
PojoLocator.find(Key<?>(Organization(1)/Person(2)))
通过调用,OrderDao.findOrganizationById
我已经收到了完整的对象图。为什么.find
还要打两次电话呢?这是Datastore上的额外负载,这使我花了很多钱。我当然缓存了它,但是对其进行修复很简洁。如何避免这些额外的电话?
当我通过saveOrganization
在客户端中调用来保存对象时,也会发生类似的事情。服务器端发生以下调用:
PojoLocator.find(Key<?>(Organization(1)))
PojoLocator.find(Key<?>(Organization(1)/Person(2)))
OrderDao.saveOrganization(1)
PojoLocator.getId(Key<?>(Organization(1)))
PojoLocator.find(Key<?>(Organization(1)))
PojoLocator.getId(Key<?>(Organization(1)/Person(2)))
PojoLocator.find(Key<?>(Organization(1)/Person(2)))
我可以理解需要 在* 更新 之前
从DataStore提取两个对象。RequestFactory将增量发送到服务器,因此在持久存储之前,它需要具有整个对象。不过,由于我一次加载了完整图表,因此最好不要再调用第二个PojoLocator.find(Key<?>(Organization(1)/Person(2)))
。坚持下来
之后 ,我真的不明白需要.find()
打来的电话。 *
有什么想法吗?
我的代理
@ProxyFor(value = Organization.class,locator = PojoLocator.class)
public interface OrganizationProxy extends EntityProxy
{
public String getName();
public void setName(String name);
public String getAddress();
public void setAddress(String address);
public PersonProxy getContactPerson();
public void setContactPerson(PersonProxy contactPerson);
public EntityProxyId<OrganizationProxy> stableId();
}
@ProxyFor(value = Person.class,locator = PojoLocator.class)
public interface PersonProxy extends EntityProxy
{
public String getName();
public void setName(String name);
public String getPhoneNumber();
public void setPhoneNumber(String phoneNumber);
public String getEmail();
public void setEmail(String email);
public OrganizationProxy getOrganization();
public void setOrganization(OrganizationProxy organization);
}
我的服务
public interface AdminRequestFactory extends RequestFactory
{
@Service(value = OrderDao.class,locator = InjectingServiceLocator.class)
public interface OrderRequestContext extends RequestContext
{
Request<Void> saveOrganization(OrganizationProxy organization);
Request<OrganizationProxy> findOrganizationById(long id);
}
OrderRequestContext contextOrder();
}
最后是我的定位器<>
public class PojoLocator extends Locator<DatastoreObject,String>
{
@Inject Ofy ofy;
@Override
public DatastoreObject create(Class<? extends DatastoreObject> clazz)
{
try
{
return clazz.newInstance();
} catch (InstantiationException e)
{
throw new RuntimeException(e);
} catch (IllegalAccessException e)
{
throw new RuntimeException(e);
}
}
@Override
public DatastoreObject find(Class<? extends DatastoreObject> clazz,String id)
{
Key<DatastoreObject> key = Key.create(id);
DatastoreObject load = ofy.load(key);
return load;
}
@Override
public Class<DatastoreObject> getDomainType()
{
return null; // Never called
}
@Override
public String getId(DatastoreObject domainObject)
{
Key<DatastoreObject> key = ofy.fact().getKey(domainObject);
return key.getString();
}
@Override
public Class<String> getIdType()
{
return String.class;
}
@Override
public Object getVersion(DatastoreObject domainObject)
{
return domainObject.getVersion();
}
}
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。