conditional object assignment

  • Thread starter Thread starter ThatsIT.net.au
  • Start date Start date
T

ThatsIT.net.au

I have an application where different types of users login. depending what
role they are in they are assigned a diffrent user object, admin dataEntry
and so on.

I can do this using some if statments and then makiung a instance of the
corect object. the propble with this is that i have to do this on every
page. what i would like to do is load the same commonUserObject for each
user, and in the class then assign the right object as a child object. i
could then access the object like this


dim oUser as commonUserObject = new commonUserObject
oUser.childObject.someMethod

This will do, but i was wondering if there was a more elegent way of doing
this, can i some how make the commonUserObject morph into the right object.
 
I have an application where different types of users login. depending what
role they are in they are assigned a diffrent user object, admin dataEntry
and so on.

I can do this using some if statments and then makiung a instance of the
corect object. the propble with this is that i have to do this on every
page. what i would like to do is load the same commonUserObject for each
user, and in the class then assign the right object as a child object. i
could then access the object like this

dim oUser as commonUserObject = new commonUserObject
oUser.childObject.someMethod

This will do, but i was wondering if there was a more elegent way of doing
this, can i some how make the commonUserObject morph into the right object.
Click to expand...

Sounds like a case for creating a class and adding it to the App_Code
folder. The constructor could take the user role as a parameter and
configure itself accordingly. That way you can re-use it throughout
the whole site. Maintenance will be far easier because all the code
for setting it up wil be contained in one place.
 
I have an application where different types of users login. depending
what role they are in they are assigned a diffrent user object, admin
dataEntry and so on.

I can do this using some if statments and then makiung a instance of
the corect object. the propble with this is that i have to do this on
every page. what i would like to do is load the same commonUserObject
for each user, and in the class then assign the right object as a
child object. i could then access the object like this


dim oUser as commonUserObject = new commonUserObject
oUser.childObject.someMethod

This will do, but i was wondering if there was a more elegent way of
doing this, can i some how make the commonUserObject morph into the
right object.
Click to expand...


Set up an object with the common fields. You can load this into session
if you want to avoid going to the database all the time. For the more
specific objects, have them adorn the main user object. If you want, you
can lazy load the other object. This is where you are aiming for,
essentially.

Another method of doing this is to "subclass" the user object into more
specific objects with additional features. On pages you only need the
common bits, simply use it as a user object. On more specific pages,
GetType() and then cast as the other type of object and use the extra
bits.

If you are talking configuration bits (an employee has an SSN, but other
users do not), you can use the built in Profile bits and simply not
assign the extra items for other users. This is very flexible, but note
that the out of the box profile is a bit problematic if you get too
creative (and cleaning up a fubar is a pain). I use custom profile
providers for this reason.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************
 
Stan said:
Sounds like a case for creating a class and adding it to the App_Code
folder. The constructor could take the user role as a parameter and
configure itself accordingly. That way you can re-use it throughout
the whole site. Maintenance will be far easier because all the code
for setting it up wil be contained in one place.
Click to expand...

I think want you are sujesting is much what i have done so far, but I cant
do this in the app_code foldee as the app will have many front ends built by
whoever, what i want to do is handle all this in a lower layer.
 
Gregory A. Beamer said:
Set up an object with the common fields. You can load this into session
if you want to avoid going to the database all the time. For the more
specific objects, have them adorn the main user object. If you want, you
can lazy load the other object. This is where you are aiming for,
essentially.

Another method of doing this is to "subclass" the user object into more
specific objects with additional features. On pages you only need the
common bits, simply use it as a user object. On more specific pages,
GetType() and then cast as the other type of object and use the extra
bits.

If you are talking configuration bits (an employee has an SSN, but other
users do not), you can use the built in Profile bits and simply not
assign the extra items for other users. This is very flexible, but note
that the out of the box profile is a bit problematic if you get too
creative (and cleaning up a fubar is a pain). I use custom profile
providers for this reason.

Peace and Grace,
Click to expand...


I really dont want to do any casting or detection, well not in more than one
spot that is.
The site will have many front ends, so all the security and validation and
such will be done on a middle layer. In between my business object layer and
the front ends I have waht I am calling the user layer. here i have
different user classes derived from a abstract class. that contatin all the
methods allowed to that user. all common methods and properties are
inhertied from the abstract class. i have done things this way becuse as
long as the user has the right user object I need not worry about
authorization as he is allowed to do or access anything in his class. The
front end will only open one object the correct user object, then in return
the user object will access the bisiness object layer as if it were the
front end.

how i am doing it is fine, but I just thought it would be a little better if
i did not have to use the common.child syntax as it may be a little
confusing for the front end developers.
what i would like is to use a simple

dim oUser as commonUserObject = new commonUserObject
oUser.someMethod

rather then

dim oUser as commonUserObject = new commonUserObject
oUser.childObject.someMethod

But i can live with it

Thanks
 
how i am doing it is fine, but I just thought it would be a little
better if i did not have to use the common.child syntax as it may be a
little confusing for the front end developers.
what i would like is to use a simple

dim oUser as commonUserObject = new commonUserObject
oUser.someMethod

rather then

dim oUser as commonUserObject = new commonUserObject
oUser.childObject.someMethod
Click to expand...

I am rolling off the top of my head, so there is no filter here.

Reflection - a bit too heavy probably
Extension methods - fine, but have to handle when a method does not
exist for an object type

You might even try a combination of both, but while that will work, it
makes things more complex than the child object, so ouch on that.

The child object is certainly the safest, as a person trying a method on
a child object that is incorrect will not compile.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************
 
Gregory A. Beamer said:
I am rolling off the top of my head, so there is no filter here.

Reflection - a bit too heavy probably
Extension methods - fine, but have to handle when a method does not
exist for an object type

You might even try a combination of both, but while that will work, it
makes things more complex than the child object, so ouch on that.

The child object is certainly the safest, as a person trying a method on
a child object that is incorrect will not compile.

Peace and Grace,
Click to expand...



yes it seems to be the best answer
 
ThatsIT.net.au said:
I have an application where different types of users login. depending
what role they are in they are assigned a diffrent user object, admin
dataEntry and so on.

I can do this using some if statments and then makiung a instance of the
corect object. the propble with this is that i have to do this on every
page. what i would like to do is load the same commonUserObject for each
user, and in the class then assign the right object as a child object. i
could then access the object like this


dim oUser as commonUserObject = new commonUserObject
oUser.childObject.someMethod

This will do, but i was wondering if there was a more elegent way of
doing this, can i some how make the commonUserObject morph into the
right object.
Click to expand...

You can make the specific user objects inherit your common user object,
and use a factory method to create them:

Dim user As CommonUserObject = CommonUserObject.Create()
user.SomeMethod()

The static Create method will create a specific user object depending on
the conditions, but it's return type is still CommonUserObject.
 
Göran Andersson said:
You can make the specific user objects inherit your common user object,
and use a factory method to create them:

Dim user As CommonUserObject = CommonUserObject.Create()
user.SomeMethod()

The static Create method will create a specific user object depending on
the conditions, but it's return type is still CommonUserObject.
Click to expand...


thanks
sillly me , i had instance object in my mind and could think outside it.
thanks



 
Back
Top