Data Binding with Object Data Sources

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi experts,

I have a question concerning data binding to custom objects in a
Windows.Forms application:

I have a custom business object named "Employee". Now I created an Object
Data Source and drag it onto a form. So there is a BindingNavigator and a
DataGridView.

If I click the Delete button of the BindingNavigator, the Employee object is
removed from the employeeBindingSource.List. So far so good, but how can I
find out which Employee was deleted so that I can delete my real Employee
object in the DataBase?

The the ListChanged event of the employeeBindingSource is too late, the
object was already removed from the employeeBindingSource.List.

Thanks in advance
 
If you're storing the employees in a database why are you making a copy of
that data rather than just using a database adapter to perform an update?

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.
 
"Bob Powell [MVP]" <bob@_spamkiller_.bobpowell.net> a écrit dans le message
de eyZ5%[email protected]...

| If you're storing the employees in a database why are you making a copy of
| that data rather than just using a database adapter to perform an update?

Separation of concerns!!

The use of OPFs is becoming more common as people realise that hooking up UI
controls to database tables means that your UI has to deal with all sorts of
stuff that should really not be there.

Creating a Business Layer means that objects are stored in and loaded from a
Persistence Layer without having to know anything about what kind of storage
is being used; you can even mix storage without the business logic having to
be changed.

Fortunately, the designers of the .NET framework realised that this
separation of concerns was important to well written applications, so they
provided us with controls that can hook up to properties of business
objects, thus enabling us to write well-mannered business systems that can
be ported to any database or UI without having to change a single line of
business logic.

Joanna
 
Hi Joanna, hi Bob, thanks for your post!

well, i think there are two kinds of .Net developers out there:

The first likes DataSets and monolithic application design very much. They
use SQL statements right in the user interface code und spread their business
logic all over the application. This often leads to quick solutions but who
wants to maintain this code next year?

The second loves object oriented design and encapsulation of data and logic.
They design their application in layers (mostly presentation/business
logic/data access layers) where the presentation layer works with objects of
the business logic layer and does not know anything about the way they are
persisted.

But, what about my question? ;-)
 
"ulrich schumacher" <[email protected]> a écrit
dans le message de (e-mail address removed)...

| But, what about my question? ;-)

You need to ensure that the RaiseListChangedEvents property on the
BindingSource returns true and then handle the ListChanged event. Write code
in this event that talks to your OPF.

Joanna
 
The the ListChanged event of the employeeBindingSource is too late, the
object was already removed from the employeeBindingSource.List.

There is something needed like a ListChanging event.
In case of an exception during persisting the Employee object, the deletion
should be cancelable.
 
"ulrich schumacher" <[email protected]> a écrit
dans le message de (e-mail address removed)...

| The the ListChanged event of the employeeBindingSource is too late, the
| object was already removed from the employeeBindingSource.List.
|
| There is something needed like a ListChanging event.
| In case of an exception during persisting the Employee object, the
deletion
| should be cancelable.

In that case, you might want to derive your own class from BindingSource and
override the Remove method, raising your own OnDeleting event from there and
only calling the base method if the result of that event reports success.

Joanna
 
That's it, thanks a lot Joanna!

To Microsoft: Why do i always need those workarounds when working with
business objects instead of DataSets?
 
"ulrich schumacher" <[email protected]> a écrit
dans le message de (e-mail address removed)...

| That's it, thanks a lot Joanna!

No problem.

| To Microsoft: Why do i always need those workarounds when working with
| business objects instead of DataSets?

You should try to connect Delphi data-aware controls to business objects -
no chance, it's either database or nothing ! :-(

It can be done, but not without writing your own dataset component from
scratch or buying in some third-party solution.

At least the .NET framework is well designed and flexible enough to
accomodate changes.

Joanna
 
Back
Top