I have a program that uses a DataGridView.

It will only show one table that consist of one column and any amounts
of rows.

Should I use a DataSet or is it OK to use the DataTable directly as
DataSource?

// Anders

On 2011-08-14 20:01, Big Steel wrote:
> You can use a Datatable and bind it to a control directly. A Dataset is
> a container for one or more Datatables.
>

OK, then it's easier to use a DataTable.

> You can also use a List<T> and bind it to a control.
>

Hmmm, I have read somewhere that a list<T> has some problems when using
it as a binding source.

It's probably something I have misinterpreted....

Thank you for our answer!

// Anders

On 2011-08-14 21:58, Peter Duniho wrote:
> On 8/14/11 12:25 PM, Anders Eriksson wrote:
>> [...]
>> Hmmm, I have read somewhere that a list<T> has some problems when using
>> it as a binding source.
>>
>> It's probably something I have misinterpreted....
>
> It depends on what behavior you expect. List<T> does not offer
> notifications for changes, so it's not full-featured when used as a
> binding source. There is a BindingList<T> that is better for that purpose.
>

Now when you mention it, this is what i read!

> For many scenarios, the bound list isn't expected to change and a plain
> List<T> is fine.
>

OK, The more you know the more choices you have to make...

Thank you very much!

// Anders

On 8/14/2011 4:57 PM, Big Steel wrote:
> On 8/14/2011 4:27 PM, Anders Eriksson wrote:
>> On 2011-08-14 21:58, Peter Duniho wrote:
>>> On 8/14/11 12:25 PM, Anders Eriksson wrote:
>>>> [...]
>>>> Hmmm, I have read somewhere that a list<T> has some problems when using
>>>> it as a binding source.
>>>>
>>>> It's probably something I have misinterpreted....
>>>
>>> It depends on what behavior you expect. List<T> does not offer
>>> notifications for changes, so it's not full-featured when used as a
>>> binding source. There is a BindingList<T> that is better for that
>>> purpose.
>>>
>>
>> Now when you mention it, this is what i read!
>>
>>> For many scenarios, the bound list isn't expected to change and a plain
>>> List<T> is fine.
>>>
>>
>> OK, The more you know the more choices you have to make...
>>
>> Thank you very much!
>
> But you can make the object a smart object in the List<T>, and you can
> query for any object that is dirty by using Linq to determine if any
> object in the List<T> is dirty.
>
> After the binding of a List<T> and you need to change a property of the
> object, you can do it off of the grid's index and address the object's
> property directly.
>
> <http://www.dailycoding.com/Posts/maintaining_dirty_and_new_state_of_objects.aspx>
>
> If you send the List<T> to a Business or Data Access layer or you
> persist data by other means, then you know which persist logic to use
> for the object based on the object's state.
>
> 1) IsNew and IsDirty -- insert
> 2) !IsNew and IsDirty - update
> 3) IsDelete -- delete

Stuff like that I would expect the ORM to do without adding
user any code.

If I had to do myself I would not use the design in the link:
- require specific base class
- require code in each property set to mark it as dirty

Instead I would:
- require specific interface
- require properties to be virtual
- wrap the instances in a proxy

That is a more flexible design and mean writing a lot less code.

Arne

PS: I have an implementation using Castle if someone want to see
an example.