471,594 Members | 1,686 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,594 software developers and data experts.

Data Oriented vs Object Oriented Design

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.

--
Patrick
Nov 17 '05 #1
1 3794
> * 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.

Your post is hard to place for me, but here are a couple of thoughts:

My advise would be to stay away from generics unless you have a compelling
reason not to. Many things generics can do can be accomplished with
non-generics too, in a far easier manner. For example, using a
System.ArrayList() instead of a list generic will save you a couple of
headaches.

A DataTable can contain pretty much anything, I don't see why you would
need a value object besides the DataTable, other than for performance
reasons.

This link was posted earlier as a nice introduction to the ADO.NET stuff:
http://samples.gotdotnet.com/quickst...aceHolder.aspx

Greetings,
Wessel
Nov 17 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by cryptic_blade | last post: by
8 posts views Thread by Dale | last post: by
reply views Thread by XIAOLAOHU | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.