設計高爾夫：在appengine中建模一個地址，又名AddressProperty？

今天我重構了一些代碼，並重新訪問了一個老朋友Address類（見下文）。在我看來，在我們的應用程序中，我們沒有對地址做任何特殊處理 - 沒有查詢，只有輕量級驗證和頻繁序列化到JSON。從開發者角度來看，唯一的「有用」屬性是標籤和人員。因此，我考慮重構Address模型以使用自定義AddressProperty（見下文），這讓我覺得這是一件好事，但我沒有看到任何引人注目的優勢。設計高爾夫：在appengine中建模一個地址，又名AddressProperty？

你會選擇哪種方法，爲什麼以及什麼權衡來指導這個決定？

# a lightweight Address for form-based CRUD 
# many-to-one relationship with Person objects 
class Address(db.Model): 
    label=db.StringProperty() 
    person=db.ReferenceProperty(collection_name='addresses') 
    address1=db.StringProperty() 
    address2=db.StringProperty() 
    city=db.StringProperty() 
    zipcode=db.StringProperty() 


# an alternate representation -- worthwhile? tradeoffs? 
class Address(db.Model): 
    label=db.StringProperty() 
    person=db.ReferenceProperty(collection_name='addresses') 
    details=AddressProperty() # like db.PostalAddressProperty, more methods

來源

2010-08-12 Andrew B.

兩件事之間的選擇不是「高爾夫」:) – kennytm 2010-08-12 20:34:47

你可以添加自己的選擇 – 2010-08-12 20:35:57

一個優點是你可以抽象出所有地址都是美國人的假設。 – 2010-08-12 20:36:01