Design Pattern for Data-Centered Application

I am having a little trouble deciding how to structure an application that I am building.

The application is required to parse through text-based files (one record per line) and load all of the information into memory. There are typically anywhere from 100,000 - 500,000 records. After that, the data must be displayed in the form of tables and very detailed graphs/charts for further analysis.

The user must have the ability to customize the view of this data. For example, there are many different "types" of log records (TypeA_Log, TypeB_Log, etc.) The user should have the ability to select/deselect these types, which will show/hide them from the display. There are several other types of filtering going on (filter by date, etc.)

--

Essentially what I have now is this:

I have a class structure that represents the various types of log records.

There is a Singleton pattern to hold all of the data (almost like a database in memory), which includes Lists<> of log record instances.

Then, I have a "filter" class which contains information about what the user would like to view. The "filter" gets passed into the Data-Singleton, and then returned a subset of the data.开发者_如何学C I am basically using C# lambda expressions to select data from a List<> of Log Records, similar to how you might pass in a SELECT statement to a SQL database.

--

This is working okay, but I have to think there is a better way of handling this. Right now, anytime the user makes even the smallest change (for example, selects/deselects one of the many types of log records, a new data set has to be retrieved from the Data-Singleton, and then all of the tables and charts have to be refreshed/rebinded/recomputed to reflect this change. All I really want to do, in most cases, is show/hide certain things.

I am using C# .NET 3.5.

---

You could build some sort of internal notification system, something also called event dispatcher.

Lets say have a record changed in one form, and instead of reloading other dependent forms, you fire the event that some record has changed (attach the record with some custom EventArgs), and let your dependent forms decide on event handling should they include this new record somewhere. You could update the changed data in the collections of the dependent forms.

However, this can create some concurrency problems (when you avoid rooundtrips to the database (text files in your case) )...