DataSet vs DataTable
Anders Eriksson
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
Big Steel
a container for one or more Datatables.
You can also use a List<T> and bind it to a control.
public class Eriksson
{
public string Name {get; set;}
}
var list = new List<Eriksson>();
While in a loop you can do this.
var erk = new Eriksson
erk.Name = "Help";
list.Add(erk)
Then you can take the list and bind it do a control.
datagridview.datasource = list;
<http://msdn.microsoft.com/en-us/library/6sh2ey19.aspx>
<http://www.dotnetperls.com/list>
<http://msdn.microsoft.com/en-us/library/aa287786(v=vs.71).aspx>
<http://msdn.microsoft.com/en-us/library/bb384054.aspx>
Anders Eriksson
> 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
Big Steel
I think so.
Peter Duniho
> [...]
> 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.
For many scenarios, the bound list isn't expected to change and a plain
List<T> is fine.
Pete
Anders Eriksson
> 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
Big Steel
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
Arne Vajhøj
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.
Big Steel
Oh, I didn't know that everyone was using an ORM. Did you forget about
ADO.NET SQL Command Objects and T-SQL?
The whole world in IT programming is using an ORM solution.
Some companies I have worked in controlled by the DBA(s) will not allow
an ORM solution period.
In other situations like in a multilayer Web application, the objects
from the ORM are mapped to Data Transfer Object or Business Object and
the ORM object doesn't pass the service layer.
> 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's all nice and all. What do you want me say?
>
> 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.
>
No I don't want to see example. I don't want to have anything to do with
you.
You do what you want to do. It doesn't concern me as to what you do.
When you put out a book comparable to CSLA Business Object book by
Rocky, then you can talk.
Big Steel
One other thing here, although I have learned and implemented objects on
CSLA concepts, other areas I have used the Dofactory concepts. However,
I knew a great deal of it before I discovered Dofactory patterns.
Each one of the E-Commerce solutions are using the same back-end of WCF
Web service, BLL and DAL with Linq-2-SQL or ADO.NET Entity Framework.
Data Transfer Object are used with mapping between the ORM solution
object to DTO or it could be a Bussiness Object. The ORM objects are
left behind and don't cross the Web service.
http://www.dofactory.com/Framework/Framework.aspx
Some people like using the DTO(s) or BO and leaving the ORM behind until
such time that objects need to be persisted to the database.