Thiết kế kiến ​​trúc cho ứng dụng WP7 theo hướng dữ liệu

Question

Tôi có ứng dụng Silverlight Windows Phone 7 để lấy dữ liệu từ API công khai. Tôi thấy mình làm nhiều điều tương tự hơn và hơn nữa:

• Trong giao diện người dùng, thiết lập một thanh thông báo tải hoặc tiến bộ nạp ở vị trí của nơi mà nội dung là
• Lấy nội dung, có thể đã trong bộ nhớ, được lưu trong bộ nhớ tệp bị cô lập hoặc yêu cầu yêu cầu HTTP
• Nếu không thể có được nội dung (không có kết nối mạng, v.v.), hiển thị thông báo lỗi
• Nếu nội dung được mua, hiển thị nội dung trong giao diện người dùng
• Giữ nội dung trong bộ nhớ chính cho các truy vấn tiếp theo

Nội dung được hiển thị cho người dùng có thể được lấy trực tiếp từ nguồn dữ liệu, chẳng hạn như ObservableCollection hoặc có thể là truy vấn trên nguồn dữ liệu.

Tôi muốn yếu tố ra quá trình lặp đi lặp lại điều này vào một khuôn khổ nơi lý tưởng chỉ có nhu cầu sau được xác định:

• Nơi để hiển thị nội dung trong UI
• Các yếu tố giao diện người dùng để hiển thị trong khi tải , trên thất bại, và sự thành công
• URI của yêu cầu HTTP
• Làm thế nào để phân tích phản ứng HTTP vào cấu trúc dữ liệu mà sẽ giữ trong bộ nhớ
• vị trí của thứ e tập tin trong lưu trữ bị cô lập, nếu nó tồn tại
• Làm thế nào để phân tích các nội dung tập tin vào cấu trúc dữ liệu đó sẽ được lưu giữ trong bộ nhớ

Nghe có vẻ như rất nhiều, nhưng hai dây, ba FrameworkElement s, và hai phương pháp nhỏ hơn chi phí mà tôi hiện có.

Ngoài ra, điều này cần phải làm việc cho tuy nhiên dữ liệu được duy trì trong bộ nhớ và cần phải làm việc cho bộ sưu tập trực tiếp và truy vấn trên các bộ sưu tập đó.

Câu hỏi của tôi là:

có cái gì như thế này đã được thực hiện?

Tôi có nghĩ về chủ đề ở trên về cơ bản là sai theo một cách nào đó không?

Dưới đây là một thiết kế Tôi đang nghĩ đến việc:

Có hai thành phần, một Xem và một mô hình.

Chế độ xem được cung cấp FrameworkElement giây để tải, lỗi và thành công. Nó cũng được đưa ra một tham chiếu đến Mô hình tương ứng. Chế độ xem là một UserControl được đặt ở đâu đó trong giao diện người dùng.

Mô hình hóa một lớp được cung cấp URI cho dữ liệu, phương pháp phân tích dữ liệu và tùy chọn tên tệp cũng như cách phân tích cú pháp tệp.Nó có trách nhiệm truy xuất dữ liệu và thông báo cho Chế độ xem bất cứ khi nào thay đổi trạng thái hiện tại (tải/lỗi/thành công). Nếu dữ liệu được tải xuống từ mạng khác với bộ nhớ cache, dữ liệu mạng sẽ được ưu tiên. Khi ứng dụng đóng hoặc được sử dụng, mô hình ghi dữ liệu vào bộ nhớ cache.

Âm thanh đó như thế nào?

Answer 1

Tôi dành chút thời gian để đọc tốt các yêu cầu của bạn và lưu ý một số suy nghĩ để cung cấp như một bo mạch âm thanh.

Thứ nhất, đối với các tác vụ lặp lại với hành vi thông thường, đây chắc chắn là cách tiếp cận nó. Bạn không đơn độc trong suy nghĩ về vấn đề này.

Mọi người làm một loạt các thứ này có thể đã tạo ra các trừu tượng tương tự, tuy nhiên, theo hiểu biết của tôi, không có thông tin nào được phát hành công khai.

Bạn có thể đi xa đến mức nào nếu bạn định sử dụng cho riêng mình và cho những người có yêu cầu rất giống hoặc bạn muốn xử lý các trường hợp tổng quát hơn và làm cho sản phẩm có thể sử dụng được thính giả.

Tôi sẽ giả định cái cũ, nhưng điều đó không loại trừ khả năng phát hành nó như một dự án nguồn mở có thể được phát triển thêm và/hoặc chia nhỏ.

Bằng cách không cố gắng đáp ứng mọi khả năng bạn có thể đưa ra các giả định nhất định về bản chất của việc triển khai sử dụng và trong các lựa chọn thiết kế giao diện người dùng cụ thể.

Tôi nghĩ rằng suy nghĩ chung của bạn đi đúng hướng. Trong khi đọc một số suy nghĩ cấp cao của bạn, tôi xem xét một số điều có thể được đơn giản hóa (một điều tốt) và đồng thời cung cấp một giao diện người dùng compeling.

Trên các điểm ban đầu của bạn.

• Bạn chỉ có thể giả định một progressbar hiệu suất isindeterminate đã được thông qua trong
• Làm điều này nếu nó quan trọng với bạn, nhưng bạn có thể mua cho mình vào một số phức tạp ở đây xử lý yêu cầu bộ nhớ đệm khác nhau -. Khác biệt trong thời gian hoặc bẩn xử lý. Có lẽ đủ để dựa vào nền tảng sẵn có bộ nhớ đệm của url (mà một số người đã tìm thấy được theo cách của họ).
• Xử lý kết nối mạng, điều này lặp đi lặp lại và hơi phức tạp. Một ứng cử viên hoàn hảo cho một giải pháp chung.
• Cập nhật giao diện người dùng ... được cho là tốt hơn để chỉ trả lại dữ liệu và trì hoãn các quyết định về cách trình bày và định dạng dữ liệu cho các khách hàng cá nhân của bạn.
• Nội dung trong bộ nhớ chính - xem ở trên về bộ nhớ đệm.

Về đầu vào tiềm năng của bạn.

• Nơi hiển thị nội dung - xem dữ liệu trên và trì hoãn lựa chọn bản trình bày cho khách hàng.
• Tôi sẽ đi với phần tử giao diện người dùng cho chỉ báo tiến trình, một lần nữa là thanh tiến trình thực hiện. Về truyền thông thất bại, tôi sẽ xem xét việc thực hiện điều này trong một sự kiện đã hoàn thành mà bạn xuất bản. Sau đó, thông qua các thông số bạn có thể giao tiếp kết quả và trì hoãn xử lý cho khách hàng để đặt kết quả đó trong một số kiểm soát trình bày/log/bất cứ điều gì. Điều này phù hợp với các mẫu được sử dụng bởi .Net Framework.
• URI - vâng, điều này được chuyển vào.
• Cách phân tích cú pháp - chuyển qua một đại biểu để chuyển đổi luồng hoặc chuỗi thành một đối tượng có thể do khách hàng quyết định loại có ý nghĩa.
• Tìm bộ nhớ cache - bạn có thể vượt qua điều này nếu tổng quát vấn đề này hoặc mã hóa đường dẫn của nó. Nó sẽ hữu ích hơn cho người khác nếu được thông qua (xem xét nếu bạn xử lý các thư mục/tạo).

Khi triển khai.

• Bạn có thể sử dụng UserControl, nếu nó hoạt động để bạn bị ràng buộc bởi giả định đó. Nó sẽ linh hoạt hơn mặc dù, và cho là không kém phần đơn giản/thanh lịch, để đẩy bản trình bày trở lại trên máy khách cho cả hiển thị dữ liệu và thông điệp trạng thái và điều khiển ẩn/hiển thị thanh tiến trình như được thông qua.
• Có lẽ bạn sẽ đi xa để giả định các thông báo trạng thái sẽ luôn luôn được hiển thị trong một textblock (nếu được thông qua) và chuyển dịch vụ vệ sinh đó từ mỗi khách hàng của bạn thành lớp chung của bạn.
• Tôi nghi ngờ bạn sẽ được hưởng lợi từ việc không ghép nối định dạng dữ liệu và bản trình bày.
• Xử lý Tombstone .. Tôi muốn giới thiệu một số thử nghiệm trên nền tảng trong bộ đệm ẩn của URL tại đây và xem liệu bạn có thể xác định liệu thời lượng/điều kiện bẩn có hoạt động cho các trường hợp chung của bạn hay không.

Hy vọng điều này sẽ cung cấp cho bạn một số điều cần suy nghĩ và một số đảm bảo bạn đang đi đúng hướng. Có rất nhiều cách bạn có thể đi về việc này. Đó là con đường tốt nhất cuối cùng sẽ được thúc đẩy bởi mục tiêu của bạn.

Answer 2

Tôi đang phát triển một ứng dụng WP7 về cơ bản là một khách hàng của một API REST hiện có. Máy chủ trả về dữ liệu bằng JSON. Với sự trợ giúp của thư viện JSON.NET (http://json.codeplex.com/) tôi đã có thể deserialize nó trực tiếp đến các lớp .NET C# của tôi.

Tôi lưu trữ cục bộ dữ liệu để xử lý tình huống ngoại tuyến của ứng dụng và cũng để ngăn chặn cuộc gọi trên máy chủ mỗi khi người dùng khởi chạy ứng dụng. Tôi cung cấp hai cách để làm mới dữ liệu: theo cách thủ công và/hoặc sau một khoảng thời gian. Để lưu trữ dữ liệu tôi sử dụng Sertling (http://sterling.codeplex.com/), đây là một cơ sở dữ liệu cục bộ đơn giản nhưng dễ sử dụng cho Silverlight/WP7.

Thách thức lớn nhất là xử lý giao tiếp không đồng bộ với máy chủ. Tôi cung cấp phản hồi giao diện người dùng rõ ràng (Progressbar và/hoặc bánh xe tải) để cho người dùng biết điều gì đang xảy ra.

Lưu ý rằng tôi đang sử dụng bộ công cụ Light MVVM và SL Unit Testing để thực hiện kiểm tra tích hợp View Model => local Client code => Server. (http://code.google.com/p/nunit-silverlight/wiki/NunitTestsWp7)