🚀 go-pugleaf

Andrea,

>Well, my problem is more conceptual than practical.
>I mean, I wrote a couple of classes in C#, but I am not
>really sure if I'm following the right path here.

Well then lets start with the concept.
You have a DBFieldSet with a collection of DBFields whcih seems similar to the fields of a table row.
You also have a DBRecordContentSet with a collection of DBRecordContent objects.
It seems almost as if you are trying to do the same thing two different ways here.

It really sounds like you are trying to duplicate a lot of functionality that .NET already provides. For example it already supplies a lot of the structure for you with Datasets. The framework and IDEs have a lot of integration with this concept so you would lose a lot of advantages by duplicating them.

It would make more sense to write an Engine which fits into the ADO.NET framework. (ie write a provider with classes implementing IDBConnection, IDBDataAdapter, IDBReader, etc.)

>The very problem I am fighting now with that approach is
>sorting, because I can't see an easy and clear way to it.
>There're several options I thought of:
>1) Events/Callback methods: this would allow me to just override a
>    method and be happy. Using IComparer shouldnt' be too hard to do.
>2) IComparable: This would mean adding a base class that implements the
>    interface and have virtual methods which can be overridden for
>    sorting, but - really - I don't like it too much in principle.
>3) Other options?

Most container classes provide both options. (Except that they use a delegate instead of IComparer) and using the IComparable method actually just creates an IComparer implementation which calls IComparable.


A few things with your code:

* SD supplies (or at least used to) a wizard to create collections with most of the interfaces already supported.
Although you probably want to support IBindingList as well.

* Unless you are going to compile this into its own assembly I would define the base methods as 'protected' and not 'internal protected'

* By supplying destructors. eg:
~DBRecordContent(){
  Items = null;
}
You are really implementing a Finalizer. Doing so forces the GC to require to do a lot of extra work to collect your classes. It will have to do two passes instead of one and your object will be forced into the next GC stage therefore taking far longer to be released. In this case the code does nothing that the GC isn't already capable of doing anyway.


Marc Rohloff
--TeamB

Marc Rohloff [TeamB] wrote:

> Andrea,

Hi Marc,

> Well then lets start with the concept.

Ok, I'm listening.

> You have a DBFieldSet with a collection of DBFields whcih seems similar to the fields of a table row.
> You also have a DBRecordContentSet with a collection of DBRecordContent objects.
> It seems almost as if you are trying to do the same thing two different ways here.

Er... the idea was to keep separated field definitions from
field contents, yes - maybe needs rewording.

> It would make more sense to write an Engine which fits into the ADO.NET framework. (ie write a provider with classes implementing IDBConnection, IDBDataAdapter, IDBReader, etc.)

That was the "next step" after having made my own classes.

I will however take a close look at those interfaces to see what they
have to offer... would you mind pointing me to any concrete
classes I may look for the basic structures I need( i.e. fields,
records, etc )?

> Most container classes provide both options. (Except that they use a delegate instead of IComparer) and using the IComparable method actually just creates an IComparer implementation which calls IComparable.

Ok.

> A few things with your code:

I'm all eyes :-)

> * SD supplies (or at least used to) a wizard to create collections with most of the interfaces already supported.
> Although you probably want to support IBindingList as well.

What would be the advantage with the latter interface?

> * Unless you are going to compile this into its own assembly I would define the base methods as 'protected' and not 'internal protected'

You got it right, it'll be its own assembly :-)

> * By supplying destructors. eg:
> ~DBRecordContent(){
>   Items = null;
> }
> You are really implementing a Finalizer. Doing so forces the GC to require to do a lot of extra work to collect your classes. It will have to do two passes instead of one and your object will be forced into the next GC stage therefore taking far longer to be released. In this case the code does nothing that the GC isn't already capable of doing anyway.

OUCH! You mean it would be greatly slowed down?

> Marc Rohloff
> --TeamB

Andrew

Andrea Raimondi <rainaple@tin.it> wrote:

>Er... the idea was to keep separated field definitions from
>field contents, yes - maybe needs rewording.
Yes or some documentation. Delphi used Field and FieldDef.

>would you mind pointing me to any concrete
>classes I may look for the basic structures I need( i.e. fields,
>records, etc )?
Apart from DataSet, DataTable, DataRow and DataColumn you could also look at SQLConnection, SQLCommand, SQLReader, SQLDataAdapter.


>> Although you probably want to support IBindingList as well.
>What would be the advantage with the latter interface?
It gives the ability to sort and search and can also provide information about data changes and record editability.
You will see that it automatically pulls in a few other interfaces.

>You got it right, it'll be its own assembly :-)
I would still recommend that you start off by defining your methods with the lowest access level and only increasing it when you really, really, really need to.


>OUCH! You mean it would be greatly slowed down?
Well maybe the only way to really know is to measure it.
MS highly recommends you don't define finalizers except when you are wrapping unmanaged resources (files, memory, windows handles) even then you have to be careful. For example not only the object that has the finalizer, but everything that it refers to recursively, is delayed for finalization. This can potentially have a huge impact.

 Marc Rohloff
 --TeamB

Marc Rohloff [TeamB] wrote:
> Yes or some documentation. Delphi used Field and FieldDef.

I know, but I didn't want to be so shameless to even use the
same names <g>

> Apart from DataSet, DataTable, DataRow and DataColumn you could also look at SQLConnection, SQLCommand, SQLReader, SQLDataAdapter.

Those are generic classes to derive from to implement
your very own engine?

> It gives the ability to sort and search and can also provide information about data changes and record editability.
> You will see that it automatically pulls in a few other interfaces.

Cool :-)

Definitely worth a look then! ^_^

> I would still recommend that you start off by defining your methods with the lowest access level and only increasing it when you really, really, really need to.

Ok ok :-)

> Well maybe the only way to really know is to measure it.
> MS highly recommends you don't define finalizers except when you are wrapping unmanaged resources (files, memory, windows handles) even then you have to be careful. For example not only the object that has the finalizer, but everything that it refers to recursively, is delayed for finalization. This can potentially have a huge impact.

ouch!

-_-

Fine then :-)

Thanx a lot, I have loads of material now to figure things out
much better :-)

>  Marc Rohloff
>  --TeamB

Andrew

On Mon, 16 Aug 2004 23:52:39 +0200, Andrea Raimondi wrote:

>> Apart from DataSet, DataTable, DataRow and DataColumn you could also look at SQLConnection, SQLCommand, SQLReader, SQLDataAdapter.
> 
> Those are generic classes to derive from to implement
> your very own engine?
No you asked for concrete examples.

-- 
Marc Rohloff [TeamB]
marc rohloff at myrealbox dot com