views:

24

answers:

2

In this example, the Google App Engine documentation makes the Customer the entity group parent of the AccountInfo entity. Wouldn't AccountInfo encapsulate Customer rather than the other way around? Normally I would think of an AccountInfo class as including all of the information about the Customer.

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);
+2  A: 

In real life a Customer can have more than one Account, for instance a current account and a savings account. Customers which are organisations rather than individuals may have several accounts for various different purposes.

Consequently, it makes perfect sense to have a single Customer entity which can own one or more AccountInfo entities.

APC
Exactly. A customer can have man accounts (and obviously "customer" should actually be "entity" - as in business, legal or personal entity - with a customer / supplier / employee role attachced, because your customer may also be your supplier at the same time´, unless you encode the role in the accountinfo - but then an "entity" also needs to have multiple accounts.
TomTom
A: 

Customers belong to Accounts - not the other way around. The Account is your main entity. The Account will have a variety of responsible parties depending on what the account is for. A bank account will have one or more 'Liable Party' and one or more Signee and probably one or more Account Statement Recipient. A 'customer' is an abstract notion that is only relevant in a given context - although marketing departments may keep a list of customers for mailing.

If I were doing this then I would define my scope of work as if the 'customer' ids/names are being provided from outside the scope I.E. they are a given.

NB Think you have a bank account? You don't. The bank owns the account. They set it up and give you permission to use it. From your 'real world' you might consider that you are crediting 'your' account. In the REAL 'real world' the bank is in fact debiting the account that it's giving you access (for as long as it decides to). The monies that you have just 'credited' your account with are listed as a liability by the bank since they now owe you money.

'In The Real World' is a bogus cliche used by those that find business analysis too hard. Projects are taking longer to produce the goods now than they ever did - due in part to people defining business concepts around a common view of the world. The only thing that doesn't get screwed up by these Real Worlders are accounting systems since there are specific rules that govern them. Glossary of Terms - try defining Customer! Tricky eh?

Clive Fletcher