serialize vs database

[Arne Vajhøj]

Ironically, I suspect that in this particular situation, there never
really should have been a type with 85 properties. Instead, it probably
would have made more sense to use a dictionary/indexer/etc. and have the
caller just provide the name as a string, rather than having it baked
into the code. Such an approach will be more flexible as the options for
data evolve, and is likely to be more compatible/convenient with at
least some of the use scenarios that are going to come up (i.e. setting
or retrieving these properties when the tag for the data is already a
string).

It is easy.

But it is not type safe.

And it could become pretty messy.

I'd much rather have:

class Container
{
private Dictionary<string, int> _data =
new Dictionary<string, int>();

public int this[string key]
{
get { return _data[key]; }
set { _data[key] = value; }
}
}

…used like this:

private Container _container;

void UpdateLabel(Label label, string key)
{
label.Text = _container[key].ToString();
}

That is pretty easy.

But is that method a frequent requirement??

than this:

class Container
{
public int Key1 { get; set; }
public int Key2 { get; set; }
.
.
.
public int Key85 { get; set; }
}

…used like this:

private Container _container;

void UpdateLabel(Label label, string key)
{
switch (key)
{
case "Key1":
label.Text = _container.Key1.ToString();
break;
case "Key2":
label.Text = _container.Key2.ToString();
break;
case "Key3":
label.Text = _container.Key3.ToString();
break;
.
.
.
case "Key85":
label.Text = _container.Key85.ToString();
break;
}
}

Arne

 

[Arne Vajhøj]

[...]

Ironically, I suspect that in this particular situation, there never
really should have been a type with 85 properties. Instead, it probably
would have made more sense to use a dictionary/indexer/etc. and have the
caller just provide the name as a string, rather than having it baked
into the code. Such an approach will be more flexible as the options for
data evolve, and is likely to be more compatible/convenient with at
least some of the use scenarios that are going to come up (i.e. setting
or retrieving these properties when the tag for the data is already a
string).

It is easy.

But it is not type safe.

That depends on the type of the data. In this particular situation, it
appears that all of the data are strings obtained from a web query.

I don't think OP mentioned data types.

Your example used int for values.

But the missing type safe it not from having single value type
(or from using object as value type), but from using string
as index instead of named properties.

In
any case, type-safety is not always the highest priority. .NET is filled
with very useful APIs that return things only as System.Object.

The .NET API actually often tries to put the critical
data as properties even when taking the Dictionary approach.

HttpWebRequest and HttpWebResponse handling of headers
are examples of that.

So MS knows there is problems with the Dictionary approach.

They can not avoid it completely in those two classes because
of the possibility of custom headers.

But OP can probably avoid it.

So no need to lead him astray.

No, it couldn't.

Sure it could.

You can not guarantee against keys being misspelled.

I'd much rather have:

class Container
{
private Dictionary<string, int> _data =
new Dictionary<string, int>();

public int this[string key]
{
get { return _data[key]; }
set { _data[key] = value; }
}
}

Does that class provide any value over Dictionary<string, int> ?

Yes. It encapsulates the dictionary behavior without exposing the
dictionary itself.

But what of Dictionary is not needed and potentially harmful?

I can only see Remove as a candidate. And not as a super
convincing candidate as the value can still be set to null.

There also is the implicit assumption that one can
include other scenario-specific features in the class.

Sure.

But maybe one of those cases where a bit of YAGNI could be
applied.

Whether these are useful to the OP is impossible to say. It's just a
suggestion for a pattern to use, and as is always the case when you take
things so literally, you criticize out of context.

I don't think I omitted anything relevant from what I commented on.

If I did, then I apologize. That was not the intent.

But I will obviously comment on suggestion that I find
either good or bad.

…used like this:

private Container _container;

void UpdateLabel(Label label, string key)
{
label.Text = _container[key].ToString();
}

That is pretty easy.

But is that method a frequent requirement??

There is nothing about my post that discusses "frequent". The point is
simply with respect to this specific scenario.

It is possible to come up with many scenarios that makes
certain constructs useful.

But without knowing that a specific rare scenario applies,
then I would design after the more common scenarios.

Arne