Question Updateable DataGridView Bound to Database-Drive Business Object

[aychekay]

I'd like to have an updateable DataGridView that's bound to a database-driven business object. It needs to handle all aspects of CRUD and be sortable and filterable as well.

I'm relatively new to VB.Net so I'm having trouble making sense out of the examples I have found. Most of them simply bind to an object (non-database, manually filled) and do not allow you to Add, Delete, and Edit records. Furthermore, they basically never show how you would perform sorting and filtering.

I think the biggest things I'm not understanding are:
1) How do you make the DataGridView perform additions, deletions, and edits on an object.
2) How do you program your object to handle additions, deletions, and edits. Do you just need methods that use ADO.Net, NHibernate, or Linq to SQL (or any other CRUD handling mechanism)?
3) How to make this filterable and sortable.

Is this overly difficult to do or why am I have so much trouble finding examples for this? Can anyone point me in the right direction?

 

[jmcilhinney]

You should check this out:

Custom Typed Collections and Data-binding Support

Note that you need to implement IBindingList to support simple sorting and IBindingListView to support complex sorting and filtering. The reason that binding a DataTable is so easy is because it implements IListSource and its GetList method returns its DefaultView, which is a DataView, which implements IBindingListView. The items in a DataView are type DataRowView, which also implements IEditableObject.

 

[aychekay]

Thanks for pointing me to that example. I guess I'm trying to learn too many new things at once. I'm also trying to figure out how to put my data access in it's own layer and my business logic in it's own layer. It's been a little hard for me to see how all of these different pieces of the puzzle work together.

In Access VBA (which I'm fluent in) there is really no way to build domain objects, data access layers, or business logic layers. Data Access is usually handled by Access unless you choose to do something non-standard. Default data access doesn't require any discussions about when to actually update the database as the concept of disconnected data in Access doesn't exist unless you choose to use some non-standard approach such as unbound forms or disconnected ADO recordsets. Business logic usually gets built into the form. Data binding is very simple and doesn't involved discussions about IThis and IThat interfaces. Sorting is built into the Access interface and is relatively easy to add for your runtime clients. Filtering is also very simple as all you need to do is create your filter and set it to the form's filter property.

.Net in comparison, is extremely overwhelming, especially if you want to follow the recommendations of many of the professionals and use separate layers and bind your form controls to custom objects instead of ADO.Net DataViews.