2010-10-22 26 views
5

Tôi đang xây dựng một ứng dụng đa ngôn ngữ, đa thời gian và n-tier. Tất cả các ngày được lưu trữ trong cơ sở dữ liệu trong UTC và tất cả các đối tượng mô hình được phổ biến với thời gian UTC. Tuy nhiên thời gian UTC không bao giờ được hiển thị (trừ khi người dùng xảy ra có múi giờ được đặt ở UTC).Nơi cần chuyển đổi giá trị bản trình bày trong kiến ​​trúc nhiều tầng?

Điều này có nghĩa là tôi cần phải chuyển đổi thuộc tính thời gian thành múi giờ người dùng chính xác lặp đi lặp lại. Lặp lại luôn luôn là dấu hiệu của mã xấu hoặc một cách tốt hơn vì vậy tôi đã cố gắng để làm việc ra chiến lược tốt nhất để thực hiện. Mặc dù điều này là logic trình bày hiệu quả suy nghĩ của tôi đã được thay đổi bởi vì nó có vẻ như là nếu mô hình nên biết các giá trị phù hợp cho người dùng hiện tại. Cho đến nay suy nghĩ của tôi là:

  1. Sử dụng lớp trợ giúp tĩnh và sau đó gọi nó mỗi lần sử dụng mô hình. Điều này có vẻ dễ bị lỗi hoặc bị lãng quên và làm cho và tính toán rườm rà.

  2. Quấn đối tượng mô hình vào đối tượng chế độ xem. Điều này cũng không kém phần rườm rà nhất là khi giao dịch với danh sách các đối tượng.

  3. Viết phương thức mở rộng cho mô hình chỉ tồn tại trong lớp trình bày. Điều này có vẻ sạch hơn nhưng không trực quan.

  4. Tạo giao diện trong lớp mô hình cho chuyển đổi. Triển khai trình trợ giúp trong lớp trình bày và cung cấp cho lớp mô hình triển khai thực hiện. Mô hình sau đó có các thuộc tính sử dụng giao diện để chuyển đổi thời gian. Điều này có vẻ như nó nên được chia tách mối quan tâm nhưng không xuất hiện. Nếu bạn có một công cụ chuyển đổi mặc định thì bạn sẽ không phải lo lắng về việc nhận các ngoại lệ đối tượng null tuy nhiên lớp mô hình (hiện tại là POCO) sẽ cần một thùng chứa cho trình trợ giúp chuyển đổi có vẻ lộn xộn.

  5. Tạo chuyển đổi sang phương pháp múi giờ địa phương trên mô hình và chuyển vào múi giờ hiện tại.

Tôi quan tâm đến các chiến lược này hoặc bất kỳ chiến lược nào khác mà tôi nên hoặc có thể sử dụng thay cho các chiến lược này.

Cập nhật Điều tôi hiện đang thực hiện là tạo ITimeConvertor và ITimeConvertorFactory trong lớp mô hình. Sau đó tôi đã tạo các triển khai mặc định trong số này, chỉ trả lại giá trị ngày ban đầu. Trong lớp mô hình, tôi đã thêm thuộc tính localtime cho mỗi thuộc tính UTC hiện có ban đầu trên mô hình. Trong các thuộc tính này, tôi sử dụng nhà máy để có được một công cụ chuyển đổi và chuyển đổi giá trị UTC theo cách thức trong getter và setter. Tôi đã phải thêm một lớp cài đặt tĩnh với trong lớp mô hình (mà tôi không thực sự thích) như là một nơi để lưu trữ nhà máy timeconvertor hiện tại. Trong phần ứng dụng web, tôi triển khai ITimeConvertorFactory và ITimeConvertor là WebTimeConvertorFactory và WebTimeConvertor. WebTimeConvertor biết về phiên và người dùng hiện tại để có thể lấy múi giờ hiện tại. WebTimeConvertorFactory tạo WebTimeConvertors. Khi ứng dụng khởi động (application_onstart trong global.asax), tôi tạo nhà máy và chuyển nó tới thuộc tính thiết lập tĩnh của lớp mô hình. Điều này cho phép lớp mô hình của tôi có thể chuyển đổi giờ địa phương trong khi lớp dữ liệu chỉ biết về các thuộc tính ngày UTC. Điều đó cũng có nghĩa là tôi có thể chuyển trực tiếp các giờ địa phương vào mô hình và chuyển đổi nó chính xác miễn là ứng dụng tiêu thụ đã cung cấp một nhà máy chuyển đổi. Vì thuộc tính UTC không thay đổi, chúng vẫn có thể được sử dụng ở bất kỳ đâu trong ứng dụng. Trong khi nó có vẻ như rất nhiều mã, tôi đã tìm thấy giải pháp này khá sạch sẽ khi nó cho phép người tiêu dùng khác của dịch vụ thực hiện chuyển đổi thời gian của họ dù họ muốn (nếu có) trong khi vẫn giữ tiêu thụ các đặc tính mô hình hợp lý rõ ràng.

Tôi vẫn mở cho các giải pháp và phê bình tốt hơn về giải pháp hiện tại của mình.

Trả lời

2

Tôi cho rằng đó là lớp mô hình của bạn biết về múi giờ của người dùng, do đó, nó lên đến lớp mô hình để chuyển đổi thuộc tính thời gian. Nếu không, bạn sẽ phải để lớp trình bày biết về múi giờ và chuyển đổi từng giá trị thời gian ở đó.

Giá trị thời gian chuyển đổi trong lớp mô hình sẽ cho phép sử dụng chúng trong lớp bản trình bày mà không có bất kỳ chuyển đổi nào, vì vậy tôi nghĩ rằng sẽ sạch sẽ. Ví dụ, bạn có thể khởi tạo các đối tượng của bạn (POCO) với thời gian được chuyển đổi ngay từ đầu. Nhưng hãy cẩn thận khi tái chuyển đổi chúng trong mô hình, quên rằng chúng đã được khởi tạo vào thời gian cục bộ. Ngoài ra, nếu người dùng có thể chỉnh sửa các giá trị thời gian, bạn sẽ cần phải chuyển đổi chúng trở lại thời gian UTC trước khi bạn lưu.

Cập nhật: Sau một vài suy nghĩ nhiều hơn, tôi thu thập rằng thời gian tính theo giờ UTC là một phần của mô hình và localtimes là một cái nhìn của mô hình này, vì vậy nhiệm vụ chuyển đổi thuộc ở những lớp trình bày (tại các chi phí của không đồng ý với riêng tôi). Với cùng một quá trình suy nghĩ, có các thuộc tính cục bộ cùng với thời gian UTC là bản sao trong bản chất, và chuyển đổi vẫn còn trong lớp mô hình. Để khắc phục điều này, bạn có thể có một thuộc tính loại UTCToLocalTimeConverter chỉ đọc trong người dùng POCO được khởi tạo với múi giờ (cũng loại bỏ sự cần thiết của các phương thức tĩnh). Sau đó, tất cả các cuộc gọi đến thuộc tính thời gian trong các trang sẽ được bao bọc trong phương thức ConvertToLocalTime của trình chuyển đổi, có thể truy cập được qua người dùng. Bạn cũng có thể đặt cá thể chuyển đổi trực tiếp trong Session nếu muốn.

Tôi không biết liệu phương pháp này có phù hợp với bạn không, nhưng nó được lấy cảm hứng từ chiến lược của bạn và tôi nghĩ phần còn lại của thiết kế chạy trơn tru hơn theo cách này. Ngoài ra việc chuyển đổi sang giờ địa phương vẫn được xử lý bởi khách hàng. Nhược điểm là có để chuyển đổi tất cả các giá trị thời gian trong khách hàng, nhưng điều đó dường như với tôi như là một điều ác cần thiết để đổi lấy việc loại bỏ dữ liệu trùng lặp và phương pháp tĩnh.

+0

Tôi đoán đó là một số quan điểm của tôi, lớp mô hình của tôi có biết múi giờ của người dùng không? Hiện tại không có. Cuộc tranh luận nội bộ của tôi là liệu đây có phải là một quyết định của lớp trình bày hay mô hình hay không. Người dùng POCO lưu trữ múi giờ nhưng người dùng POCO không có thuộc tính thời gian mà các POCO khác thực hiện. Vì vậy, tôi sau đó buộc hiển thị các giá trị từ một POCO đến một giá trị khác không cần thiết trước đây ... – toxaq

+0

Tôi đã cập nhật câu trả lời của mình. – henginy

+0

Tuyệt vời, cảm ơn. Tôi thấy những gì bạn đang nói và đối với tôi nó thực sự là một sự quăng lên giữa hai 'tệ nạn cần thiết'. Vì tôi thích sự đơn giản của tiêu thụ (và vì tôi hiện là người duy nhất làm việc trên nó), tôi sẽ gắn bó với tôi trong thời gian này nhưng tôi nghĩ rằng bạn có giá trị như nhau và chắc chắn trong suốt/dễ đọc hơn. – toxaq

Các vấn đề liên quan