P
Patrick
Hi all,
New to .NET, I'm working on an Winforms client application using VS
2005 beta2. My needs considering data storage are the followings:
(1) Small files (0 < length < 10 mb), containing lots of small
'objects' that need to be loaded into memory at runtime, in order to
garantee small access time to each 'object'. Each of these 'objects'
collection should be able to easily bind to a DataGridView, AND to
provide *filtering* and *sorting* capability.
(2) 'Mid-large' files (0 < length < 100 mb), containing lots of
'mid-large objects'. Such files shouldn't be fully loaded in memory,
but the class that deals with those files must expose random
accessing/adding/removing/modifying 'object' functionalities.
In facts, a file of type (1) contains an index of the large 'objects'
contained in a corresponding file of type (2). Each index will be used
to fill a DataGridView, and each entry (row) will provide a
'reference' to the 'big object' stored in the corresponding type (2)
file (in addition to some other object-specific details that will be
displayed on the DGView of course).
Since this is a light Windows client application, using a database
with a data provider is out of the question.
Type (2) will be the subject of another post ("Dealing with large
files (random access)").
So let's talk about type (1):
My first thought was to use one or more DataSet objects to deal with
all of these. But as no data providers would be used, I said to myself
that considering a collection of objects would be better: thus I could
use serialization to store and retrieve usable objects, instead of
DataRows. So I took a look at the new C# 2.0 generics and found myself
pretty satisfied: the generic List<T> class provided in .NET 2.0
seemed to be perfect for my indexes (type (1)). Binding it to a (.NET
2.0) Windows.Forms.BindingSource, and then this BindingSource to my
DataGridView would then be just great, because (from MSDN):
"Sorting and filtering capability is exposed in the BindingSource
control through the Sort and Filter properties. Simple sorting can be
applied when the underlying data source is an IBindingList, and
advanced filtering and sorting can be applied when the data source is
an IBindingListView."
That was too easy: the only class implementing IBindingListView in
..NET 2.0 is DataView. Implementing it for a List<T> would be too much
work. So back to my first idea: I finally had to use a DataSet for my
type (1) files. IMHO, this is far from being the 'killer' approach.
Well, .NET 2.0 seem to have made a great progress by introducing a new
abstract layer for data binding: the BindingSource class. The UI is no
more directly tied to some data object. But there's still something
wrong: I constantly need a value object to do more things than just
reading and modifying my current entry. A DataViewRow, even if it
'represents' an entry, can't contain the smarts of an object.
To sum up:
* The OO generics approach provides usable objects but few sorting and
no filtering capabilities.
* The DataTable approach provides full sorting and filtering but no
usable objects.
I would be glad to read your comments about these thoughts. And
please, if I miss something about .NET data binding capability (or
other), tell me.
New to .NET, I'm working on an Winforms client application using VS
2005 beta2. My needs considering data storage are the followings:
(1) Small files (0 < length < 10 mb), containing lots of small
'objects' that need to be loaded into memory at runtime, in order to
garantee small access time to each 'object'. Each of these 'objects'
collection should be able to easily bind to a DataGridView, AND to
provide *filtering* and *sorting* capability.
(2) 'Mid-large' files (0 < length < 100 mb), containing lots of
'mid-large objects'. Such files shouldn't be fully loaded in memory,
but the class that deals with those files must expose random
accessing/adding/removing/modifying 'object' functionalities.
In facts, a file of type (1) contains an index of the large 'objects'
contained in a corresponding file of type (2). Each index will be used
to fill a DataGridView, and each entry (row) will provide a
'reference' to the 'big object' stored in the corresponding type (2)
file (in addition to some other object-specific details that will be
displayed on the DGView of course).
Since this is a light Windows client application, using a database
with a data provider is out of the question.
Type (2) will be the subject of another post ("Dealing with large
files (random access)").
So let's talk about type (1):
My first thought was to use one or more DataSet objects to deal with
all of these. But as no data providers would be used, I said to myself
that considering a collection of objects would be better: thus I could
use serialization to store and retrieve usable objects, instead of
DataRows. So I took a look at the new C# 2.0 generics and found myself
pretty satisfied: the generic List<T> class provided in .NET 2.0
seemed to be perfect for my indexes (type (1)). Binding it to a (.NET
2.0) Windows.Forms.BindingSource, and then this BindingSource to my
DataGridView would then be just great, because (from MSDN):
"Sorting and filtering capability is exposed in the BindingSource
control through the Sort and Filter properties. Simple sorting can be
applied when the underlying data source is an IBindingList, and
advanced filtering and sorting can be applied when the data source is
an IBindingListView."
That was too easy: the only class implementing IBindingListView in
..NET 2.0 is DataView. Implementing it for a List<T> would be too much
work. So back to my first idea: I finally had to use a DataSet for my
type (1) files. IMHO, this is far from being the 'killer' approach.
Well, .NET 2.0 seem to have made a great progress by introducing a new
abstract layer for data binding: the BindingSource class. The UI is no
more directly tied to some data object. But there's still something
wrong: I constantly need a value object to do more things than just
reading and modifying my current entry. A DataViewRow, even if it
'represents' an entry, can't contain the smarts of an object.
To sum up:
* The OO generics approach provides usable objects but few sorting and
no filtering capabilities.
* The DataTable approach provides full sorting and filtering but no
usable objects.
I would be glad to read your comments about these thoughts. And
please, if I miss something about .NET data binding capability (or
other), tell me.