Seeking Design Advice

Seeking Design Advice

Old forum URL: forums.lhotka.net/forums/t/7895.aspx


Jack posted on Wednesday, October 28, 2009

I have a scheduling component to my application that I need to provide a UI for in two separate places.

The first UI is a very simplified version that lets you clickly flag tasks as booked, completed, cancelled or just to view, sort, and see what is out there.  If the user needs to do more advanced scheduling, such as uncancelling, bulk updates, re-assigning, etc then they have to use the SuperUI.

The actual UI isn't that big a deal except that I'm showing the same UI in lots of different places depending on what scope of detail they are managing.

The tricky part is that there is a lot of scheduling data and I need to retrieve it in chunks as they peruse different parts of the application.  The chunks are really different views of the master schedule data. 

The schedule data is of the format

Master Task
   - Visit
   - Task

So a single parent has two sets of children.  As a participant comes in for so many visits they complete the tasks.  The actual data isn't that relevant for my problem.

You can retrieve/view/edut the schedule for:

My Schedule - everything that pertains to me in a date range
Participant Schedule - everything a study participant has to do ...
Staff Schedule - everything that a staff member needs to do
Site Schedule - everything for all participants / staff at a site
Program Schedule - Site schedule for all sites in the program.

So my problem is that there is a lot of replication.  I'd like to maintain a single big list on the client and refresh chunks of it as they navigate to new areas of the application or back to previously visited one.

If this was a server app I wouldn't worry about and I'd just re-retrieve the data all the time and keep multiple subsets all over the place but with clients all over the US using the Internet to get the data I need to cache the data locally as much as possible.

I'm thinking maybe I need to do it in two stages where the BO pull from a DAL that actually exists on the client and the DAL itself pulls from the database.  Sort of like the InventoryDemo but with another layer that actually pulls from the database...

Anybody doing anything similar?

Any ideas on how to structure it so that to the user it appears as though it is always being retreived in chunks? 

Thanks

jack

decius replied on Wednesday, October 28, 2009

Seems to me you're just battling the age old granularity question, "How coarse/fine should I make it?". 

IMHO, it sounds to me like I would make each "list" an EditableRootList, thus giving it it's own DAL. This would give you the finer granularity you need and you can just call the Get whenever you want to update the UI data (as they navigate to new areas of the application as you say).

Copyright (c) Marimer LLC