Constructor reading Session Variables
-
Don't know if this qualifies as a coding horror, but it does give me the heebeegeebees. Classes that have constructors which initialise the member variables of the class. So far so good. Except the constructor gets the values it needs from Session Variables, rather than parameters passed in to the constructor. I understand why it was done, one of the classes is being used to write data to a table that has 118 columns. Who wants to pass 118 parameters to a constructor? But it still seems questionable to me. To put it simply you can instantiate the same class twice and end up with radically different states depending on how the Session Variables look at the time. What say you? Coding Horror? Common Practice? Both? In a strange twist, there is generally a function that is called that sets all the necessary session variables before the class is instantiated. I don't see why the class couldn't be instantiated first and then have this method set properties on the class rather than setting session variables.
-
Don't know if this qualifies as a coding horror, but it does give me the heebeegeebees. Classes that have constructors which initialise the member variables of the class. So far so good. Except the constructor gets the values it needs from Session Variables, rather than parameters passed in to the constructor. I understand why it was done, one of the classes is being used to write data to a table that has 118 columns. Who wants to pass 118 parameters to a constructor? But it still seems questionable to me. To put it simply you can instantiate the same class twice and end up with radically different states depending on how the Session Variables look at the time. What say you? Coding Horror? Common Practice? Both? In a strange twist, there is generally a function that is called that sets all the necessary session variables before the class is instantiated. I don't see why the class couldn't be instantiated first and then have this method set properties on the class rather than setting session variables.
-
Don't know if this qualifies as a coding horror, but it does give me the heebeegeebees. Classes that have constructors which initialise the member variables of the class. So far so good. Except the constructor gets the values it needs from Session Variables, rather than parameters passed in to the constructor. I understand why it was done, one of the classes is being used to write data to a table that has 118 columns. Who wants to pass 118 parameters to a constructor? But it still seems questionable to me. To put it simply you can instantiate the same class twice and end up with radically different states depending on how the Session Variables look at the time. What say you? Coding Horror? Common Practice? Both? In a strange twist, there is generally a function that is called that sets all the necessary session variables before the class is instantiated. I don't see why the class couldn't be instantiated first and then have this method set properties on the class rather than setting session variables.
I agree; can't the variables be passed into the constructor as a collection?
-
I wish that a 118 column table was the biggest horror in that Database. I've had an intermittent fantasy for about 10 years now leave programming behind and become a train driver. That DB has rekindled that dream. -Rd
-
I agree; can't the variables be passed into the constructor as a collection?
Or just a structure... It could even have a static method to fill itself from the session variables...
MyClass spork = new MyClass(MyClassArgs.LoadFromSession());
Same effect, a bit more verbose, but actually makes it obvious what's happening.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
Or just a structure... It could even have a static method to fill itself from the session variables...
MyClass spork = new MyClass(MyClassArgs.LoadFromSession());
Same effect, a bit more verbose, but actually makes it obvious what's happening.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)Both would be improvements. I think the real horror and a very very common horror is the overuse and misuse of Session Variables. These classes creating themselves from session variables are a symptom of that. In reality if you have all these session variables, the class might as well not have any properties, since it then just turns around and writes it's properties to the DB. Why not just write the Session variables to the DB? Or why even bother with a class? If you're nailing your colors to the mast of Session variables then a Sub in a Module would do the same job. Time for someone to write "Session Variables Considered Harmful" Session variables are actually worse than traditional Global Variables, yet I rarely hear that much fuss about them. In this day and age shouldn't we be required to declare Session Variables explicitly and also make them typesafe? The more of other people's ASP.Net code that I have to maintain, the more I despise these little devils. -Rd
-
118 Columns, pfft.. that's child's play. Oh, right that's not something to be proud of, right?
-
Both would be improvements. I think the real horror and a very very common horror is the overuse and misuse of Session Variables. These classes creating themselves from session variables are a symptom of that. In reality if you have all these session variables, the class might as well not have any properties, since it then just turns around and writes it's properties to the DB. Why not just write the Session variables to the DB? Or why even bother with a class? If you're nailing your colors to the mast of Session variables then a Sub in a Module would do the same job. Time for someone to write "Session Variables Considered Harmful" Session variables are actually worse than traditional Global Variables, yet I rarely hear that much fuss about them. In this day and age shouldn't we be required to declare Session Variables explicitly and also make them typesafe? The more of other people's ASP.Net code that I have to maintain, the more I despise these little devils. -Rd
How true. Did I ever mention the problems caused by a great thinker who stored dynamically created ASP.Net controls in the session? The session state is member of the page object. The entries in the session state are controls, which again have a reference to the page. Circle complete. Now, what was this about a garbage collection and when exactly does it clean up?
A while ago he asked me what he should have printed on my business cards. I said 'Wizard'. I read books which nobody else understand. Then I do something which nobody understands. After that the computer does something which nobody understands. When asked, I say things about the results which nobody understand. But everybody expects miracles from me on a regular basis. Looks to me like the classical definition of a wizard.
-
How true. Did I ever mention the problems caused by a great thinker who stored dynamically created ASP.Net controls in the session? The session state is member of the page object. The entries in the session state are controls, which again have a reference to the page. Circle complete. Now, what was this about a garbage collection and when exactly does it clean up?
A while ago he asked me what he should have printed on my business cards. I said 'Wizard'. I read books which nobody else understand. Then I do something which nobody understands. After that the computer does something which nobody understands. When asked, I say things about the results which nobody understand. But everybody expects miracles from me on a regular basis. Looks to me like the classical definition of a wizard.
What is the end of the session? I'll take Coding Horrors for $500 Alex.
-
Don't know if this qualifies as a coding horror, but it does give me the heebeegeebees. Classes that have constructors which initialise the member variables of the class. So far so good. Except the constructor gets the values it needs from Session Variables, rather than parameters passed in to the constructor. I understand why it was done, one of the classes is being used to write data to a table that has 118 columns. Who wants to pass 118 parameters to a constructor? But it still seems questionable to me. To put it simply you can instantiate the same class twice and end up with radically different states depending on how the Session Variables look at the time. What say you? Coding Horror? Common Practice? Both? In a strange twist, there is generally a function that is called that sets all the necessary session variables before the class is instantiated. I don't see why the class couldn't be instantiated first and then have this method set properties on the class rather than setting session variables.
:omg: :wtf:
Regards - Kunal Chowdhury | Software Developer | Blog | Twitter | Silverlight Tutorial | Indian Forum
-
GibbleCH wrote:
A table with 118 columns? That's the biggest horror
:omg: Might be a Fresher's work!!!
Regards - Kunal Chowdhury | Software Developer | Blog | Twitter | Silverlight Tutorial | Indian Forum