Explicitly create data object bound to control

[frankswildyearstom]

Hello,

I read somewhere that one of few weaknesses in data binding model is
that you never explicitly handle or create the data object that’s
bound to the control and as a result you don’t have a chance to add an
extra item, but I’m not sure what is meant by that.

What or how exactly would you be able to add an extra item if you were
allowed to explicitly create a data object? Would you basicaly be able
to bind control to data source and let the runtime automaticly fill
the control with data source’s data , and additionaly that control
could also get an extra item from data source by manualy creating it?
How would it be able to do that?


thanx much

 

[Pavel Minaev]

I read somewhere that one of few weaknesses in data binding model is
that you never explicitly handle or create the data object that’s
bound to the control and as a result you don’t have a chance to add an
extra item, but I’m not sure what is meant by that.

What they mean is that, say, you have a list of customers, and you
have a combo box where you want to display that list, but you also
want an extra item such as "<No customer>". And if the list of
customers comes from your business objects layer, it shouldn't have
such a thing.

What or how exactly would you be able to add an extra item if you were
allowed to explicitly create a data object? Would you basicaly be able
to bind control to data source and let the runtime automaticly fill
the control with data source’s data , and additionaly that control
could also get an extra item from data source by manualy creating it?
How would it be able to do that?

Typically, you'd wrap the collection of business objects returned to
you into a new one that pretends to contain that extra special item
when asked, and then bind to that.

 

[frankswildyearstom]

What they mean is that, say, you have a list of customers, and you
have a combo box where you want to display that list, but you also
want an extra item such as "<No customer>". And if the list of
customers comes from your business objects layer, it shouldn't have
such a thing.

-- Just for the clarification – by list of items you are referring to
a data object which we should never explicitly create and <no
customer> is an extra item?

-- In terms of ASP.NET, if we create write a data access component
that we bind to some control ( via data source control ), then
technically speaking, we did explicitly create data object that is
bound to a control?
But I suspect something else is meant by “never explicitly create
data object that is bound to control”?

--Why should it matter whether list of customers comes from business
or data layer?
I thought we aren’t able to explicitly handle or create data objects
that are bound to control even if we wanted to – but you are
suggesting it is more of a design thing?

Typically, you'd wrap the collection of business objects returned to
you into a new one that pretends to contain that extra special item
when asked, and then bind to that.

Are we advised against such a design logic?

 

[Pavel Minaev]

-- Just for the clarification – by list of items you are referring to
a data object which we should never explicitly create and <no
customer> is an extra item?

Yes.

Note that "never explicitly create" is a rather meaningless statement.
Someone has to create it somewhere, and since it's presumably a
collection of objects of some class that you define, then you'll have
to create it.

-- In terms of ASP.NET, if we create write a data access component
that we bind to some control ( via data source control ), then
technically speaking, we did explicitly create data object that is
bound to a control?

If we are talking about ObjectDataSource, then no, since it's not a
"data object" (I think that you might actually be meaning "business
object" by that). The class that you feed to ObjectDataSource is not
itself a business object - it's just a glue.

But I suspect something else is meant by  “never explicitly create
data object that is bound to control”?

I strongly suspect that they rather mean not to manually fill the
control with child controls (i.e. iterate over the list, create a
ListItem for each element and add it to the ListBox, and so on). If
you're dealing with business objects, they are supposed to be created
(or otherwise obtained) by the business layer anyway, so you just ask
it to "get all customers with first name X". It will still have to
create those objects somewhere, but it won't be in UI code.

--Why should  it matter whether list of  customers comes from business
or data layer?

For this purpose it doesn't.

I thought we aren’t able to explicitly handle or create data objects
that are bound to control even if we wanted to – but you are
suggesting it is more of a design thing?

It this point I would ask you to define what a "data object" is but
whatever it may be, I don't see why you wouldn't be able to do that. I
mean, you can certainly write:

listBox.DataSource = new[] { new { Name = "John", Age = 31 }, new
{ Name = "Jane", Age = 27 }, ... };

Are we advised against such a design logic?

I don't see anything wrong with it. Such a wrapper would be more glue.
There's nothing wrong with that. Of course, it's better to write it
just once, so I'd write a generic wrapper for any two collections
(optionally observable) that exposes them as a single collection, and
delegates all operations (including subscriptions to and notifications
of CollectionChanged, if available on the original collections).

 

[Pavel Minaev]

What or how exactly would you be able to add an extra item if you were
allowed to explicitly create a data object? Would you basicaly be able
to bind control to data source and let the runtime automaticly fill
the control with data source’s data , and additionaly that control
could also get an extra item from data source by manualy creating it?
How would it be able to do that?

By the way, if you are asking this question not in a general sense,
but for a specific framework, then you may get a more specific answer.
WPF in particular has some pretty neat ways of injecting extra items
in data bound controls (see CompositeCollection class, and
particularly the samples for it on MSDN), and ASP.NET can bind to any
IEnumerable, and doesn't need change notifications from collections,
which means that one can just use Enumerable.Concat(). The principles
are really the same as I've outlined before - you still bind a control
to a wrapper "glue" collection that injects the extra items - but you
use stock solutions provided for that purpose. If we're talking about
WinForms, then you're not so lucky...

 

[frankswildyearstom]

I would ask you to define what a "data object" is

I’m not sure anymore. First I thought “data object” is a data source
that can supply data to ObjectDataControl ( thus data object would be
class we specify with TypeName attribute ), but perhaps “Data object”
is the data which data source supplies to ObjectDataControl. Here’s
the exact quote ( perhaps you can figure out what the quote meant by
“data object” ):

"Earlier, you saw an example that allowed users to browse a list of
cities in different regions using two linked controls—a DropDownList
and a GridView. Best of all, this example could be created using a
SqlDataSource or an ObjectDataSource; either way, it doesn’t require
any custom code.
As convenient as this example is, it presents a problem that’s
difficult to fix. Because it’s impossible to create a drop-down list
that doesn’t have a selected item (unless it’s empty), the first city
in the list is automatically selected. Many web applications use a
different behavior and add an extra item at the top of the list with
text such as “(Choose a City)”. Selecting this first item has no
effect.
Additionally, you might want to add an item that allows you to see
every city in a single list.
So, how can you implement this model with data binding?
One of the few weaknesses in the data binding model is that you never
explicitly handle or create the data object that’s bound to the
control. As a result, you don’t have the chance to add an extra item.
In fact, this example has two
challenges—determining how to add the extra options to the list and
reacting when they are selected to override the automatic query
logic."

Yes.

Note that "never explicitly create" is a rather meaningless statement.
Someone has to create it somewhere, and since it's presumably a
collection of objects of some class that you define, then you'll have
to create it.


If we are talking about ObjectDataSource, then no, since it's not a
"data object" (I think that you might actually be meaning "business
object" by that).

I didn’t mean to imply that ObjectDataSource was a “data object” i.e.
”data access component”. By “data access component” ( i.e. “data
object” ) I meant a class that we specify in TypeName attribute –>
thus in case of <TypeName=”EmployeeDB”>, the data object is EmployeeDB
instance ( though as noted in the beginning of my post, the term
“data object” perhaps really means data returned by EmployeeID class )

The class that you feed to ObjectDataSource is not itself a business object -
it's just a glue.

By “class you feed to” are you referring to EmployeeDB or to a class
which EmployeeDB instance returns to ObjectDataSource ?

I strongly suspect that they rather mean not to manually fill the
control with child controls (i.e. iterate over the list, create a
ListItem for each element and add it to the ListBox, and so on). If
you're dealing with business objects, they are supposed to be created
(or otherwise obtained) by the business layer anyway, so you just ask
it to "get all customers with first name X". It will still have to
create those objects somewhere, but it won't be in UI code.


For this purpose it doesn't.


It this point I would ask you to define what a "data object" is

See the beginning of my post

but
whatever it may be, I don't see why you wouldn't be able to do that. I
mean, you can certainly write:

  listBox.DataSource = new[] { new { Name = "John", Age = 31 }, new
{ Name = "Jane", Age = 27 }, ... };

Are we advised against such a design logic?

I don't see anything wrong with it. Such a wrapper would be more glue.
There's nothing wrong with that. Of course, it's better to write it
just once, so I'd write a generic wrapper for any two collections
(optionally observable) that exposes them as a single collection, and
delegates all operations (including subscriptions to and notifications
of CollectionChanged, if available on the original collections).

 

[frankswildyearstom]

I would ask you to define what a "data object" is

I’m not sure anymore. First I thought “data object” is a data source
that can supply data to ObjectDataControl ( thus data object would be
class we specify with TypeName attribute ), but perhaps “Data object”
is the data which data source supplies to ObjectDataControl. Here’s
the exact quote ( perhaps you can figure out what the quote meant by
“data object” ):

"Earlier, you saw an example that allowed users to browse a list of
cities in different regions using two linked controls—a DropDownList
and a GridView. Best of all, this example could be created using a
SqlDataSource or an ObjectDataSource; either way, it doesn’t require
any custom code.
As convenient as this example is, it presents a problem that’s
difficult to fix. Because it’s impossible to create a drop-down list
that doesn’t have a selected item (unless it’s empty), the first city
in the list is automatically selected. Many web applications use a
different behavior and add an extra item at the top of the list with
text such as “(Choose a City)”. Selecting this first item has no
effect.
Additionally, you might want to add an item that allows you to see
every city in a single list.
So, how can you implement this model with data binding?
One of the few weaknesses in the data binding model is that you never
explicitly handle or create the data object that’s bound to the
control. As a result, you don’t have the chance to add an extra item.
In fact, this example has two challenges—determining how to add the
extra options to the list and reacting when they are selected to
override the automatic query logic."

Yes.

Note that "never explicitly create" is a rather meaningless statement.
Someone has to create it somewhere, and since it's presumably a
collection of objects of some class that you define, then you'll have
to create it.


If we are talking about ObjectDataSource, then no, since it's not a
"data object" (I think that you might actually be meaning "business
object" by that).

I didn’t mean to imply that ObjectDataSource was a “data object” i.e.
”data access component”. By “data access component” ( i.e. “data
object” ) I meant a class that we specify in TypeName attribute –>
thus in case of <TypeName=”EmployeeDB”>, the data object is EmployeeDB
instance ( though as noted in the beginning of my post, the term
“data object” perhaps really means data returned by EmployeeID class )

The class that you feed to ObjectDataSource is not itself a business object -
it's just a glue.

By “class you feed to” are you referring to EmployeeDB or to a class
which EmployeeDB instance returns to ObjectDataSource ?

I strongly suspect that they rather mean not to manually fill the
control with child controls (i.e. iterate over the list, create a
ListItem for each element and add it to the ListBox, and so on). If
you're dealing with business objects, they are supposed to be created
(or otherwise obtained) by the business layer anyway, so you just ask
it to "get all customers with first name X". It will still have to
create those objects somewhere, but it won't be in UI code.


For this purpose it doesn't.


It this point I would ask you to define what a "data object" is

See the beginning of my post

but
whatever it may be, I don't see why you wouldn't be able to do that. I
mean, you can certainly write:

listBox.DataSource = new[] { new { Name = "John", Age = 31 }, new
{ Name = "Jane", Age = 27 }, ... };

 

[Pavel Minaev]

I’m not sure anymore. First I thought “data object” is a data source
that can supply  data to ObjectDataControl ( thus data object would be
class we specify with TypeName attribute ), but perhaps “Data object”
is the data which data source supplies to ObjectDataControl. Here’s
the exact quote ( perhaps you can figure out what the quote meant by
“data object” ):

"Earlier, you saw an example that allowed users to browse a list of
cities in different regions using two linked controls—a DropDownList
and a GridView. Best of all, this example could be created using a
SqlDataSource or an ObjectDataSource; either way, it doesn’t require
any custom code.
As convenient as this example is, it presents a problem that’s
difficult to fix. Because it’s impossible to create a drop-down list
that doesn’t have a selected item (unless it’s empty), the first city
in the list is automatically selected. Many web applications use a
different behavior and add an extra item at the top of the list with
text such as “(Choose a City)”. Selecting this first item has no
effect.
Additionally, you might want to add an item that allows you to see
every city in a single list.
So, how can you implement this model with data binding?
One of the few weaknesses in the data binding model is that you never
explicitly handle or create the data object that’s bound to the
control. As a result, you don’t have the chance to add an extra item.
In fact, this example has two challenges—determining how to add the
extra options to the list and reacting when they are selected to
override the automatic query logic."

Yeah, they seem to mean "data object" as in "object bound to a
specific item in the combobox" - which is usually business/domain
objects, though not necessarily so, depending on the architecture.

I didn’t mean to imply that ObjectDataSource was a “data object” i.e.
”data access component”. By “data access component” ( i.e. “data
object” ) I meant a class that we specify in TypeName attribute –>
thus in case of <TypeName=”EmployeeDB”>, the data object is EmployeeDB
instance

That still isn't a business object (nor a "data object" in a sense
implied by the fragment you've quoted).

 ( though as noted in the beginning of my post, the term
“data object” perhaps really means data returned by EmployeeID class )

Yup.

 

[beginwithl]

hello,

Yeah, they seem to mean "data object" as in "object bound to a
specific item in the combobox" - which is usually business/domain
objects, though not necessarily so, depending on the architecture.

So business/domain objects are any objects that are passed from
business layer to some other layer?

Yup.

It seems you use terms “business object” and “data object”
interchangeablly. Do they mean the same thing ( in our case data
passed from EmployeeID class to ObjectDataSource)?


I must confess that I’m still not quite sure what the quote meant by
claiming that we can’t explicitly create/handle “data objects”?

 

[Pavel Minaev]

It seems you use terms “business object” and “data object”
interchangeablly. Do they mean the same thing ( in our case data
passed from  EmployeeID class to ObjectDataSource)?

They do not really mean the same, but in this context, as far as the
data-bound UI control is concerned, they are the same thing: they are
individual objects that contain the data it renders. I guess "data
object" is a decent umbrella term for that, though it's certainly not
a universal one.

I must confess that I’m still  not quite sure what the quote meant by
claiming that we can’t explicitly create/handle “data objects”?

To be honest, I've no idea. The closest I can get to that is that you
should not explicitly create "data objects" in UI layer - you should
get them from the business logic layer. Aside from that... well, maybe
you should write an email to the author and ask him what he meant

 

[beginwithl]

To be honest, I've no idea. The closest I can get to that is that you
should not explicitly create "data objects" in UI layer - you should
get them from the business logic layer. Aside from that... well, maybe
you should write an email to the author and ask him what he meant

It's probably not that important anyway

thanx for the help

 

[frankswildyearstom]

To be honest, I've no idea. The closest I can get to that is that you
should not explicitly create "data objects" in UI layer - you should
get them from the business logic layer. Aside from that... well, maybe
you should write an email to the author and ask him what he meant

It's probably not that important anyway

Thanx much for your help