我一直在考慮這個問題。以下是我迄今爲止的一些想法，我想知道別人怎麼想。
谷歌和雅虎的地理編碼服務都使用xAL（及其姐妹，包括個人名稱，XNAL），這給了它一定的權重。但是由於可以用許多不同的方式在xAL中描述相同的地址 - 一些比其他地方更具體 - 然後我沒有看到xAL本身是如何用於數據存儲的可接受的格式。它的一些字段名稱可以使用，然而，但在現實中，可以在16個國家中使用的基本格式，我公司船舶如下：
enum address-fields
{
name,
company-name,
street-lines[], // up to 4 free-type street lines
county/sublocality,
city/town/district,
state/province/region/territory,
postal-code,
country
}
這是很容易映射到一個單一的數據庫表，只允許大多數列的NULL。亞馬遜和許多組織實際上存儲地址數據似乎就是這樣。所以現在仍然存在的問題是，我應該如何在一個容易被程序員和任何GUI代碼使用的對象模型中對它進行建模。我們是否有一個基地Address類型與每類地址的子類，如AmericanAddress,CanadianAddress,GermanAddress，等等？這些地址類型中的每一個都知道如何格式化自己，並且可以選擇知道一些關於字段驗證的信息。
他們還可以返回一些類型的元數據的關於每個字段，如下面的僞數據結構：
structure address-field-metadata
{
field-number, // corresponds to the enumeration above
field-index, // the order in which the field is usually displayed
field-name, // a "localized" name; US == "State", CA == "Province", etc
is-applicable, // whether or not the field is even looked at/valid
is-required, // whether or not the field is required
validation-regex, // an optional regex to apply against the field
allowed-values[] // an optional array of specific values the field can be set to
}
事實上，而不是每個國家單獨的地址對象，我們可以採取讓一個Address避免的對象稍微少一些面向對象的方法。NET特性和用途的AddressStrategy以確定的格式和驗證規則：
object address
{
set-field(field-number, field-value),
address-strategy
}
object address-strategy
{
validate-field(field-number, field-value),
cleanse-address(address),
format-address(address, formatting-options)
}
當設置一個字段，即Address對象將援引其內部AddressStrategy對象上的適當的方法。
使用SetField()方法方法而不是使用getter和setter屬性的原因是，代碼更容易以通用方式實際設置這些字段，而無需使用反射或切換語句。
你能想象的過程會是這樣的：
- GUI代碼調用工廠方法或一些這樣的創建基於一個國家的地址。 （然後，國家/地區下拉菜單是客戶選擇的第一項內容，或根據文化信息或IP地址爲他們預先選好的猜測）。
- GUI調用
address.GetMetadata()或類似的方法，並接收如上所述的AddressFieldMetadata結構。它可以使用此元數據來確定要顯示哪些字段（忽略is-applicable設置爲false），標記這些字段的內容（使用field-name成員），按特定順序顯示這些字段，以及執行粗略的表示級驗證該數據（使用is-required，validation-regex和allowed-values成員）。
- GUI使用
field-number（對應於上面的枚舉）及其給定值調用address.SetField()方法。然後Address對象或其策略可以在這些領域進行一些先進的地址驗證，調用地址清潔工等
可能有上述的微小變化，如果我們想使Address對象本身表現得像一個不變對象一旦創建。 （我可能會這樣做，因爲Address對象實際上更像是一個數據結構，並且可能永遠不會有與其本身相關的任何真實行爲。）
這是否有任何意義？我偏離OOP路徑太遠了嗎？對我而言，這是一個非常明智的折衷辦法，因爲這樣抽象，實現幾乎是不可能的（xAL），而不是嚴格偏向於美國。
更新2年後：我終於結束了一個類似的系統，並在my defunct blog寫它。
我覺得這個解決方案是傳統數據和關係數據存儲之間的平衡點，至少在電子商務領域是這樣。
在哪個國家/地區？地址格式和組成在不同國家之間差異很大。如果你只處理一個國家的話，那麼這個模型比你想以結構化方式存儲來自任何國家的地址要簡單得多...... – KristoferA 2008-09-24 09:34:07
法國將是完美的;-)你是對的：單一國家地址（美國將是最常見的，我相信）將是一個很好的起點。 – Mac 2008-09-24 09:45:58