Looking for Better Way to Write Property

[Jonathan Wood]

Greetings,

I often find myself writing public properties in my ASP.NET code and I need
the ability to robustly handle cases where the property has not been set.

So I often end up with code like this:

public Guid PresenterID
{
get
{
object obj = ViewState["PresenterID"];
if (obj == null)
return null;
return (Guid)obj;
}
set { ViewState["PresenterID"] = value; }
}

My get seem overly complex because if I typecast the result of ViewState, I
get an error if it's null. I think I can use the as keyword to return
nullable datatypes whether they are null or not. But for non-nullable data
types, it seems like extra code is needed to workaround C#'s seemingly
arbitrary limitations.

I know it's not a lot of code, but I have to do something like this so
often. Can anyone offer a more efficient way to write this code?

Thanks.

Jonathan

[Kalpesh]

return (ViewState["PresenterID"] as Guid);

On Aug 18, 10:08*am, "Jonathan Wood" <[e-mail]:

Greetings,

I often find myself writing public properties in my ASP.NET code and I need
the ability to robustly handle cases where the property has not been set.

So I often end up with code like this:

*public Guid PresenterID
*{
* get
* {
* *object obj = ViewState["PresenterID"];
* *if (obj == null)
* * return null;
* *return (Guid)obj;
* }
* set { ViewState["PresenterID"] = value; }
*}

My get seem overly complex because if I typecast the result of ViewState,I
get an error if it's null. I think I can use the as keyword to return
nullable datatypes whether they are null or not. But for non-nullable data
types, it seems like extra code is needed to workaround C#'s seemingly
arbitrary limitations.

I know it's not a lot of code, but I have to do something like this so
often. Can anyone offer a more efficient way to write this code?

Thanks.

Jonathan

[Jonathan Wood]

Er... Well, actually, looks like that code wouldn't compile since I was
returning null and Guid isn't nullable. More of the same, unfortunately.

Jonathan

"Jonathan Wood" <jw***@softcircuits.comwrote in message
news:eL**************@TK2MSFTNGP06.phx.gbl...

Greetings,

I often find myself writing public properties in my ASP.NET code and I
need the ability to robustly handle cases where the property has not been
set.

So I often end up with code like this:

public Guid PresenterID
{
get
{
object obj = ViewState["PresenterID"];
if (obj == null)
return null;
return (Guid)obj;
}
set { ViewState["PresenterID"] = value; }
}

My get seem overly complex because if I typecast the result of ViewState,
I get an error if it's null. I think I can use the as keyword to return
nullable datatypes whether they are null or not. But for non-nullable data
types, it seems like extra code is needed to workaround C#'s seemingly
arbitrary limitations.

I know it's not a lot of code, but I have to do something like this so
often. Can anyone offer a more efficient way to write this code?

Thanks.

Jonathan

[Kalpesh]

Maybe you should store Nullable<Guidinto viewstate.

On Aug 18, 10:27*am, "Jonathan Wood" <[e-mail]:

Er... Well, actually, looks like that code wouldn't compile since I was
returning null and Guid isn't nullable. More of the same, unfortunately.

Jonathan

"Jonathan Wood" <[e-mail] in message

news:eL**************@TK2MSFTNGP06.phx.gbl...

Greetings,

I often find myself writing public properties in my ASP.NET code and I
need the ability to robustly handle cases where the property has not been
set.

So I often end up with code like this:

public Guid PresenterID
{
*get
*{
* object obj = ViewState["PresenterID"];
* if (obj == null)
* *return null;
* return (Guid)obj;
*}
*set { ViewState["PresenterID"] = value; }
}

My get seem overly complex because if I typecast the result of ViewState,
I get an error if it's null. I think I can use the as keyword to return
nullable datatypes whether they are null or not. But for non-nullable data
types, it seems like extra code is needed to workaround C#'s seemingly
arbitrary limitations.

I know it's not a lot of code, but I have to do something like this so
often. Can anyone offer a more efficient way to write this code?

Thanks.

Jonathan

[Jonathan Wood]

Kalpesh,

return (ViewState["PresenterID"] as Guid);

That would be a nice, simple fix wouldn't it? But it won't compile (Guid is
not nullable).

Maybe you should store Nullable<Guidinto viewstate.

Maybe. I'm not familiar with that. I'll poke around.

Thanks.

Jonathan

[Pavel Minaev]

On Aug 18, 9:53*pm, "Jonathan Wood" <[e-mail]:

Kalpesh,

return (ViewState["PresenterID"] as Guid);

That would be a nice, simple fix wouldn't it? But it won't compile (Guid is
not nullable).

Regardless of whether the value was nullable or not nullable when you
boxed it, you can always unbox it into a nullabe value, and check for
null. So:

ViewState["PresentedID"] = Guid.NewGuid(); // not nullable
...
Guid? maybeGuid = ViewState["PresentedID"] as Guid?; // still works,
null unboxes to null
if (maybeGuid != null)
{
Guid guid = (Guid)maybeGuid;
}

[Peter Duniho]

On Tue, 19 Aug 2008 00:05:05 -0700, Pavel Minaev <in****@gmail.comwrote:

Regardless of whether the value was nullable or not nullable when you
boxed it, you can always unbox it into a nullabe value, and check for
null. So:

ViewState["PresentedID"] = Guid.NewGuid(); // not nullable
...
Guid? maybeGuid = ViewState["PresentedID"] as Guid?; // still works,
null unboxes to null
if (maybeGuid != null)
{
Guid guid = (Guid)maybeGuid;
}

All due respect, I don't think the original problem was with regards to
_retrieving_ the value from "ViewState". It was with how to define the
property. It's true that the "as Guid?" can automatically convert the
returned object to a value type. But we're still left with the original
quandary.

Unless the property itself is Nullable<Guid(or some sort of nullable
type, anyway), it can't return null. In the above code, there's still the
question of what to return if "maybeGuid != null" fails to be true. Which
is what the original question was about in the first place.

The answers so far have been reasonable: one way to do it is declare the
property as Guid? (i.e. Nullable<T>) and let the caller deal with it.
Another way would be to return the default value for Guid ("return new
Guid()") instead. Again, the caller would need to check the value and
treat the default value the same as null.

Pete

[Jonathan Wood]

Pavel,

Regardless of whether the value was nullable or not nullable when you
boxed it, you can always unbox it into a nullabe value, and check for
null. So:

ViewState["PresentedID"] = Guid.NewGuid(); // not nullable
...
Guid? maybeGuid = ViewState["PresentedID"] as Guid?; // still works,
null unboxes to null
if (maybeGuid != null)
{
Guid guid = (Guid)maybeGuid;
}

Thanks, but my problem is really that I need this all the time and I'm
trying to *reduce* the amount of code and make it as simple as possible.

Based on Kalpesh's input, I came up with the following:

protected Guid? PresenterID
{
get { return ViewState["PresenterID"] as Guid?; }
set { ViewState["PresenterID"] = value; }
}

I haven't been using this long, but it appears to work so far. And it's very
short and simple. And I can compare the property to null and determine if
it's set.

Thanks.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Jonathan Wood]

Peter,

All due respect, I don't think the original problem was with regards to
_retrieving_ the value from "ViewState". It was with how to define the
property. It's true that the "as Guid?" can automatically convert the
returned object to a value type. But we're still left with the original
quandary.

Unless the property itself is Nullable<Guid(or some sort of nullable
type, anyway), it can't return null. In the above code, there's still the
question of what to return if "maybeGuid != null" fails to be true. Which
is what the original question was about in the first place.

Correct. I had done something similar before with and int property and
settled on returning -1 if there was no value, but that wasn't as straight
forward with Guid. Making the property of type Guid? seems to solve the
issue quite nicely, I thought and I will take the same approach with int
properties that may not be set in the future.

The answers so far have been reasonable: one way to do it is declare the
property as Guid? (i.e. Nullable<T>) and let the caller deal with it.
Another way would be to return the default value for Guid ("return new
Guid()") instead. Again, the caller would need to check the value and
treat the default value the same as null.

Right. The first approach and having the caller test against null suited me
best.

Thanks.

Jonathan