Tôi cũng đã nghĩ về điều này. Dưới đây là suy nghĩ của tôi cho đến nay, và tôi tự hỏi những gì người khác nghĩ.
xAL (và chị em của nó bao gồm tên cá nhân, XNAL) được cả dịch vụ mã hóa địa lý của Google và Yahoo sử dụng, cung cấp cho nó một số trọng lượng. Nhưng vì cùng một địa chỉ có thể được mô tả bằng xAL theo nhiều cách khác nhau - một số cụ thể hơn những cách khác - sau đó tôi không thấy cách chính xAL là định dạng được chấp nhận để lưu trữ dữ liệu. Một số tên trường của nó có thể được sử dụng, tuy nhiên, nhưng trong thực tế chỉ có định dạng cơ bản có thể được sử dụng trong 16 quốc gia mà tàu công ty của tôi để như sau:
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
}
Đó là đủ dễ dàng để ánh xạ vào một đơn bảng cơ sở dữ liệu, chỉ cho phép NULL trên hầu hết các cột. Và có vẻ như đây là cách Amazon và rất nhiều tổ chức thực sự lưu trữ dữ liệu địa chỉ. Vì vậy, câu hỏi vẫn còn là làm thế nào tôi nên mô hình này trong một mô hình đối tượng được dễ dàng sử dụng bởi các lập trình viên và bởi bất kỳ mã GUI nào. Chúng tôi có loại cơ sở Address với các lớp con cho từng loại địa chỉ, chẳng hạn như AmericanAddress, CanadianAddress, GermanAddress, v.v.? Mỗi loại địa chỉ này sẽ biết cách tự định dạng và tùy ý sẽ biết một chút về xác thực các trường.
Họ cũng có thể trở lại một số loại siêu dữ liệu về mỗi lĩnh vực, chẳng hạn như cấu trúc dữ liệu giả sau đây:
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
}
Trong thực tế, thay vì có đối tượng địa chỉ cá nhân cho mỗi quốc gia, chúng ta có thể lấy cách tiếp cận hướng đối tượng hơi ít có đối tượng Address tránh được.NET tài sản và sử dụng một AddressStrategy để xác định định dạng và xác nhận quy tắc:
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)
}
Khi thiết lập một lĩnh vực, đối tượng Address sẽ gọi phương thức thích hợp trên đối tượng AddressStrategy nội bộ của mình.
Lý do sử dụng phương pháp tiếp cận phương pháp SetField() thay vì thuộc tính với getters và setters là dễ dàng hơn để mã thực sự đặt các trường này theo cách tổng quát mà không cần phải phản ánh hoặc chuyển báo cáo.
Bạn có thể tưởng tượng quá trình này xảy ra một cái gì đó như thế này:
- GUI mã gọi một phương pháp nhà máy hoặc một số ví dụ để tạo ra một địa chỉ dựa trên một quốc gia. (Sự sụt giảm quốc gia, sau đó, là điều đầu tiên mà khách hàng lựa chọn, hoặc có một dự đoán tốt được lựa chọn trước cho họ dựa trên thông tin văn hóa hoặc địa chỉ IP.)
- GUI gọi
address.GetMetadata() hoặc phương pháp tương tự và nhận danh sách các cấu trúc AddressFieldMetadata như mô tả ở trên. Nó có thể sử dụng siêu dữ liệu này để xác định những trường nào hiển thị (bỏ qua những trường có is-applicable được đặt thành false), để gắn nhãn các trường đó (sử dụng thành viên field-name), hiển thị các trường đó theo thứ tự cụ thể và thực hiện xác thực cấp độ trình bày dữ liệu đó (sử dụng các thành viên is-required, validation-regex và allowed-values thành viên).
- GUI gọi phương thức
address.SetField() bằng cách sử dụng field-number (tương ứng với điều tra ở trên) và các giá trị đã cho. Các đối tượng Address hay chiến lược của nó sau đó có thể thực hiện một số xác nhận địa chỉ tiên tiến trên các lĩnh vực này, gọi tẩy rửa địa chỉ, vv
Có thể có thay đổi nhỏ trên trên nếu chúng ta muốn làm cho đối tượng Address bản thân cư xử giống như một bất biến một khi nó được tạo ra. (Mà tôi có thể sẽ cố gắng làm, vì đối tượng Address thực sự giống một cấu trúc dữ liệu hơn, và có lẽ sẽ không bao giờ có bất kỳ hành vi thực sự nào liên kết với chính nó.)
Có bất kỳ điều này hợp lý không? Tôi có đi lạc quá xa con đường OOP không? Đối với tôi, điều này thể hiện một sự thỏa hiệp khá hợp lý giữa việc quá trừu tượng đến mức việc thực hiện là không thể xảy ra (xAL) so với việc hoàn toàn bị thiên vị.
Cập nhật 2 năm sau: tôi cuối cùng đã kết thúc với một hệ thống tương tự như sau và viết về nó ở my defunct blog.
Tôi cảm thấy giải pháp này là sự cân bằng hợp lý giữa dữ liệu cũ và lưu trữ dữ liệu quan hệ, ít nhất là cho thế giới thương mại điện tử.
Ở quốc gia/quốc gia nào? Định dạng và thành phần địa chỉ thay đổi rất nhiều giữa các quốc gia khác nhau. Nếu bạn chỉ giao dịch với một quốc gia, mô hình có thể đơn giản hơn nhiều nếu bạn muốn lưu trữ địa chỉ từ bất kỳ quốc gia nào theo cách có cấu trúc .... – KristoferA
Pháp sẽ là hoàn hảo ;-) Bạn nói đúng: một quốc gia địa chỉ (Mỹ sẽ là phổ biến nhất, tôi tin) sẽ là một điểm khởi đầu tuyệt vời. – Mac