C#/OOP Frustrations:)

[Shawn Ferguson]

Hello All,

I'm starting to learn C# and OOP to become a better programmer, however I;m getting frustrated. It's tough, but what is making it really tough for me is trying to do everything with objects in mind. Here is a typical example of a scenario that I could choose different ways to approach. I have a class called Pet. Pet has an insert, update, delete, get all, get specific methods inside the class. I have a form that has the pet properties (fields) on it. I want to insert the pet (fields) properties inside a database when someone clicks the Insert Button. The first method I tried was to use the ObjectDataSource control. It doesn't work, it gives me errors on the ControlID, then when I add a control ID, it gives me a different error "Target Invocation Exception" on the ObjectDataSource.Insert() method.

So...my second thougt is to abandon the ObjectDataSource idea completely and use the methods of the object when events such as Button clicks occur. That would mean, for every button click, add, getall, edit, delete - the same object would need to be created and I would used it's proper method. It seems expensive, redundant, and not how one should use objects, but at the same time, it seems easier to understand. What are your thoughts? Thank you for all responses - frustrated, but hopeful!!!

[Mel]

In the basic way.

Create your pet class

public class Pet
{
private string color;

public string Color
{
get { return color}
set { color = value;}
}

}
then create a collection of pets

public class PetColllection : List<pet>
{
// now you can use the list to add, delete, etc...

}

Now create your new objectdatasource using the collection.

This is the very basic, hopefully it will get you started.

"Shawn Ferguson" <SF******@cscc.eduwrote in message news:%2****************@TK2MSFTNGP05.phx.gbl...
Hello All,

I'm starting to learn C# and OOP to become a better programmer, however I;m getting frustrated. It's tough, but what is making it really tough for me is trying to do everything with objects in mind. Here is a typical example of a scenario that I could choose different ways to approach. I have a class called Pet. Pet has an insert, update, delete, get all, get specific methods inside the class. I have a form that has the pet properties (fields) on it. I want to insert the pet (fields) properties inside a database when someone clicks the Insert Button. The first method I tried was to use the ObjectDataSource control. It doesn't work, it gives me errors on the ControlID, then when I add a control ID, it gives me a different error "Target Invocation Exception" on the ObjectDataSource.Insert() method.

So...my second thougt is to abandon the ObjectDataSource idea completely and use the methods of the object when events such as Button clicks occur. That would mean, for every button click, add, getall, edit, delete - the same object would need to be created and I would used it's proper method. It seems expensive, redundant, and not how one should use objects, but at the same time, it seems easier to understand. What are your thoughts? Thank you for all responses - frustrated, but hopeful!!!

[Simon Tamman]

Hi Shawn,

Great news on learning the C# and OOP stuff, trust me this stuff seriously rules but if you are moving over from a functional style it can be difficult at first to see the point.
Don't know about the ObjectDataSource (that .NET 2? Man i'm really missing out.....) but I might be able to help out with the OOP element.
To be honest the whole creating the object every operation doesn't sound to non-oop, it sounds a bit like the classic Java Petshop example. This recommands creating an object called PetADO that understands how to save your pet so that you can forward requests onto that.
E.G:

public class Pet
{

public void Save()
{
PetADO ado = new PetADO(this);
ado.Save();
}
}

I personally don't like this pattern though. I prefer to keep database concerns on the outside of the domain objects.

-<opinion>

The problem I think you are having with your understanding of OOP is that your pet object has become the world.
The persistance and displaying of the pet object should not be a concern of the pet itself. It should be more concerned about:

Yap(int loudness);
IrritateOwner();
BegForFood();
Eat(Food food);

And so forth. What you need to do is create a different object that is interested in saving stuff.
Remember that the objects saved in your database are the currency and domain of the program, they are the objects that other, more important objects use to perform tasks for the user.

In terms of data structure I usually create a DataStore object that understands all of the entities in a program in relation to persistence (saving, updating, deleting etc) and that deals with the persistence concerns.

For example: (this is not a complete example)

public class PetForm:Form
{

private IServiceProvider services;
private IDataStore dataStore;

public PetForm(IServiceProvider services)
{
this.services = services;
dataStore = (IDataStore) services.GetService(typeof(IDataStore));
this.listBox.SelectedItemChanged+= new EventHandler(listbox_SelectedItemChanged);
UpdateList();
}

/// TODO: Cache to improve performance
private void UpdateList()
{
this.listBox.DataSource = dataStore.GetList(typeof(Pet));
}

private Pet SelectedPet
{
if(listBox.SelectedItem != null)
{
return (Pet) listBox.SelectedItem;
}
else
{
return null;
}
}

private void listBox_SelectedItemChanged(object sender, EventArgs e)
{
if(SelectedPet != null)
{
BindPet(SelectedPet);
}
}

public void BindPet(Pet pet)
{
this.txtName.DataBindings.Clear();
this.txtName.DataBindings.Add("Text", pet, "Name");
}

private void btnNew_Click(some args)
{
IList list = this.listBox.DataSource as IList;
Pet pet = new Pet();
pet.Name = "New Pet";
dataStore.Save(pet);
list.Add(pet);
UpdateList();
}

private void btnUpdate_Click(some args)
{
if(SelectedPet != null)
{
dataStore.Update(SelectedPet);
}
}

private void btnDelete_Click(some args)
{
if(SelectedPet != null)
{
dataStore.Delete(SelectedPet);
UpdateList();
}
}

// etc
}

That kind of thing. (you can improve the implementation more by using currency manager and using the list as the argument to DataBindings.Add())

-</opinion>

In general all these decisions are up to you, you can develop using tables and ADO.NET, use pure SQL and either map to tables or map to objects in the datalayer or even use a ORM.
I just don't recommand getting your objects to take on too many concerns.

HTH

Simon

"Shawn Ferguson" <SF******@cscc.eduwrote in message news:%2****************@TK2MSFTNGP05.phx.gbl...
Hello All,

I'm starting to learn C# and OOP to become a better programmer, however I;m getting frustrated. It's tough, but what is making it really tough for me is trying to do everything with objects in mind. Here is a typical example of a scenario that I could choose different ways to approach. I have a class called Pet. Pet has an insert, update, delete, get all, get specific methods inside the class. I have a form that has the pet properties (fields) on it. I want to insert the pet (fields) properties inside a database when someone clicks the Insert Button. The first method I tried was to use the ObjectDataSource control. It doesn't work, it gives me errors on the ControlID, then when I add a control ID, it gives me a different error "Target Invocation Exception" on the ObjectDataSource.Insert() method.

So...my second thougt is to abandon the ObjectDataSource idea completely and use the methods of the object when events such as Button clicks occur. That would mean, for every button click, add, getall, edit, delete - the same object would need to be created and I would used it's proper method. It seems expensive, redundant, and not how one should use objects, but at the same time, it seems easier to understand. What are your thoughts? Thank you for all responses - frustrated, but hopeful!!!

[Bruce Wood]

I agree with Simon. The simplest (fewest classes) OOP model of a
business object like the one you describe would be:

1. One class for the Form, which handles display considerations, and
knows how to get information out of the form fields to build a Pet.

2. The Pet class itself, which is pure business logic and knows nothing
about Form controls or database storage.

3. A class that knows how to persist Pets into the database and read
them back again.

In my implementations, I have even more classes (!):

4. A PetValidator, which is the brains of the PetForm. It knows how to
validate user input, which fields should appear / disappear based on
values of other fields, and stuff like that. It also knows how to build
a Pet out of valid inputs (how to call the constructor for Pet). It
communicates with the PetForm using events and properties (or, in .NET
2.0, object property bindings).

5. A PetCollection, which contains only Pets, and knows how to filter /
search itself in ways specific to Pets.

I'm sure that other implementations may have even more classes.

Try starting with the first three, though, and see how it goes.