Don't worry about asking too many questions; that's the whole purpose of this forum, and especially if it's about a Wrox book... ;)
Anyway, I think if you want to stick to OO principles, you reach the point where you change a simple property into an object pretty quick. Obviously, it all depends on your preferences, knowledge, database schema and so on, but there is nothing wrong about creating objects with properties that are other objects or even collection of those objects.
I recently designed and help develop a large and clean framework on top of a broken CRM system. From a high level perspective, the system deals with "simple", real world objects like a Person, an Organization and so on. Obviously, you can't give these objects properties like:
as the number of properties quickly becomes too large to manage in a logical way. So, we designed a number of other, smaller classes, like Address (with a Type, like Shipping and Visiting), a ContactRecord (for e-mail addresses, phone numbers and so on) and many other real world objects.
A Person or an Organization class then gets properties of these types, or even collections of these types, often in the form of a Generics list, like List<Address> or List (Of Address).
Some of these lists have smart properties, like a DefaultItem, that return specific items from the underlying collection. So, assuming a Person has a list of address records called Addresses and one of those items is marked as a default item, you could do something like this:
Additionally you could create and assign an address like this:
Address myAddress = new Address();
myAddress.Street = "Some Street";
myAddress.HouseNumber = "Some Street";
myAddress.Type = AddressType.Shipping;
When you save the person with Person.Save() you look at the Addresses collection, see if it's dirty and if it is, you save the items in the database. You store each address in an Address table, and link the address to the person in an PersonAddress junction table. At load time (in a static Person.GetItem(someId) method for example), you do the reverse: look at the junction table, find all associated address records in the Address table and dump them in the Person's Addresses collection.
(These are all just examples; there are many other ways to accomplish the same thing, but hopefully you can see where this is going.)
This leaves you with a clean and easy to understand object model. Without much training, other developers should be able to understand and use this model.
Now databinding, on the other hand is, a bit trickier. It's easy to pass these complex objects from a DAL or Business Layer up to the presentation layer, but then what? Binding the main Person properties to a GridView is simple as well; the GridView will do this automatically when you bind it to a collection of Person objects.
You should also be able to, say, display the Addresses in a nested Repeater for example with some databinding code in, again for example, a RowDataBound event.
I think two-way databinding is a lot trickier, or maybe even impossible. ASP.NET has serious problems in accessing these complex objects / properties. That is, it can set something like myPerson.FirstName for you, but it won't be able to set myPerson.Addresses.Street again based on a form variable.
One solution to overcome this is to use one-way databinding. You design a form that is capable of displaying the correct properties and collections for your object. When the Save button is clicked, you get another instance of the same object from the database, then overwrite relevant properties with new entries from the form, and save the item to the database. This additional call, that isn't needed in pure two-way databinding, is, IMO, well worth the cost. It does take additional round-trips to the database, but with increased flexibility.
You can do something like this to save a Person:
Person myPerson = Person.GetItem(myId);
myPerson.FirstName = txtFirstName.Text;
Address myAddress = new Address();
myAddress.Street = txtStreet.Text;
myAddress.HouseNumber = txtHouseNumber.Text;
myAddress.Type = (AddressType) lstType.SelectedValue;
Again, just an example, but one that works for me. I am sure you have your own ideas and opinions that you want to want to blend in to this, together with opinions from co-workers or other resources, but hopefully this puts you a bit on track, inspiring you to create well-designed and easy to navigate object models and applications.
A bit of a long post again, but this is not easily explained in a few sentences.... ;)
Everyone is unique, except for me.
Author of ASP.NET 2.0 Instant Results
and Beginning Dreamweaver MX / MX 2004
While typing this post, I was listening to: She's Lost Control (12 inch)
by Joy Division
(Track 1 from the album: Heart And Soul (CD 2)
) What's This?