在此示例中，Customer或AccountInfo是否应该是实体组的父级？

在此示例中，Google App Engine documentation使AccountInfo实体的实体组父项成为Customer实体。 AccountInfo封装Customer而不是其他方式？通常我会想到AccountInfo课程包括关于Customer的所有信息。在此示例中，Customer或AccountInfo是否应该是实体组的父级？

import javax.jdo.annotations.IdGeneratorStrategy; 
import javax.jdo.annotations.PersistenceCapable; 
import javax.jdo.annotations.Persistent; 
import javax.jdo.annotations.PrimaryKey; 
import com.google.appengine.api.datastore.Key; 
import com.google.appengine.api.datastore.KeyFactory; 

@PersistenceCapable 
public class AccountInfo { 
    @PrimaryKey 
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY) 
    private Key key; 

    public void setKey(Key key) { 
     this.key = key; 
    } 
} 

// ... 
     KeyFactory.Builder keyBuilder = new KeyFactory 
     .Builder(Customer.class.getSimpleName(), "custid985135"); 

     keyBuilder.addChild(AccountInfo.class.getSimpleName(), "acctidX142516"); 

     Key key = keyBuilder.getKey(); 

     AccountInfo acct = new AccountInfo(); 
     acct.setKey(key); 
     pm.makePersistent(acct);

来源

2010-03-30 Thom Wilkie

在现实生活中，客户可以拥有多个帐户，例如当前帐户和储蓄帐户。作为组织而不是个人的客户可能有多个账户用于各种不同目的。

因此，拥有一个可以拥有一个或多个AccountInfo实体的Customer实体是非常合理的。

来源

2010-03-30 04:13:05 APC

正是。客户可以拥有人员账户（显然“客户”实际上应该是“实体” - 就像在商业，法律或个人实体中一样），并附有客户/供应商/员工角色，因为您的客户可能同时也是您的供应商。 '，除非您在accountinfo中编码角色 - 但是“实体”也需要拥有多个帐户。 – TomTom 2010-03-30 04:38:32

客户属于帐户 - 而不是相反。账户是您的主要实体。该帐户将有各种负责任的各方，具体取决于帐户的用途。银行账户将有一个或多个“可靠方”和一个或多个签署人，可能还有一个或多个账户收款人。 “客户”是一个抽象的概念，只在特定的环境中才有用 - 尽管市场部门可能会保留一份邮寄客户清单。

如果我这样做，那么我会定义我的工作范围，就好像'客户'ID /名称是从I.E以外的地方提供的。他们是一个给定的。

NB认为你有一个银行账户？你没有。银行拥有账户。他们设置并允许您使用它。从你的“真实世界”中，你可能会认为你记入了“你的”帐户。在真实的“真实世界”中，银行实际上是在为您提供访问权限的账户（只要它决定）。您刚刚“记入”您的账户的款项被银行列为责任，因为他们现在欠你钱。

'在现实世界'是一个虚假的陈词滥调，那些发现业务分析太辛苦。现在生产这些产品的时间比以往任何时候都要长，这部分是因为人们围绕着一个共同的世界观定义了商业概念。唯一不会被这些真正Worlders搞砸的是会计系统，因为有特定的规则来管理它们。术语表 - 尝试定义客户！诡计呃？

来源

2010-05-28 21:48:51

在此示例中，Customer或AccountInfo是否应该是实体组的父级？

回答

相关问题