Do I need session variables? Scoping? Extend code behind pages
I just learned about session variables from another issue. Saw the potential problem with "static variable" with multiple people browsing my site. I do not know if my structure causes an instance of BLogic for each pages code behind and I am OK, or if I have been lucky due to only two developers using the site. How would one test something like this? Am I safe?
I have 3 layers
1) forms webpage
2) code behind // for web developers, format, controls, etc., minor logic
----using WebApplication1.BusinessLo
----namespace WebApplication1.Debug
----public partial class Concantonate : System.Web.UI.Page
----protected void btnFormat_Click(object sender, EventArgs e)
----lblResultStringEmailPh
3) BusinessLogic //all major logic, business flow etc
----namespace WebApplication1.BusinessLo
----public class BLogic
----public static string UniqueMessage;
----public static string FormatEmailPhoneNumber(Con
{
Thanks
Sam
Update:
I saw a lot of redundant code that the web developers were copy/paste to many code behind pages, they are already having trouble when a bug or change is made, hours of doing the exact change to many items. To reduce this I made another c# code page where I am putting all the redundant code, one place to update or fix bug. One potential problem is multiple users (above) and the second difficult access to session variables (so I am passing parameters in function calls) , everything seems to be working. I believe there is a way to extend, inherit, or somehow hook to the code behind pages, maybe I should instantiate an instance of the BLogic in each code behind page. Sorry my question may not be very clear but I hope I have communicate the objective, how is the correct ay to do this.
Thanks Again
Sam
I have 3 layers
1) forms webpage
2) code behind // for web developers, format, controls, etc., minor logic
----using WebApplication1.BusinessLo
----namespace WebApplication1.Debug
----public partial class Concantonate : System.Web.UI.Page
----protected void btnFormat_Click(object sender, EventArgs e)
----lblResultStringEmailPh
3) BusinessLogic //all major logic, business flow etc
----namespace WebApplication1.BusinessLo
----public class BLogic
----public static string UniqueMessage;
----public static string FormatEmailPhoneNumber(Con
{
Thanks
Sam
Update:
I saw a lot of redundant code that the web developers were copy/paste to many code behind pages, they are already having trouble when a bug or change is made, hours of doing the exact change to many items. To reduce this I made another c# code page where I am putting all the redundant code, one place to update or fix bug. One potential problem is multiple users (above) and the second difficult access to session variables (so I am passing parameters in function calls) , everything seems to be working. I believe there is a way to extend, inherit, or somehow hook to the code behind pages, maybe I should instantiate an instance of the BLogic in each code behind page. Sorry my question may not be very clear but I hope I have communicate the objective, how is the correct ay to do this.
Thanks Again
Sam
Who is Participating?
Kaufmed,
Thanks so much for the visibility! Took me awhile to digest your answer, however I believe I now have one more piece to the Object Orientated Programming methodology, powerful. It is appears one can use functional programing (with objects) but miss the real benefits of OOP. I wish I could find a brief book which would contrast the two. Do you have any recommendations?
Thanks Again
Sam
Thanks so much for the visibility! Took me awhile to digest your answer, however I believe I now have one more piece to the Object Orientated Programming methodology, powerful. It is appears one can use functional programing (with objects) but miss the real benefits of OOP. I wish I could find a brief book which would contrast the two. Do you have any recommendations?
Thanks Again
Sam
It's been a while since I've actually purchased a book. Pretty much everything is online these days. Outside of that, I don't have any real suggestions.
I think you might be referring to "procedural" when you say "functional". (Maybe not.) While you can do each (to some degree) in C#, C#'s real power is in OO programming, as you've observed. In my shop, we have a lot of batch jobs that were ported over from a mainframe system. These kinds of applications tend to be more procedural in nature, with some OO sprinkled in for sugar at times. But with the deadlines we get on these conversions, we don't get a lot of time to perfect a nice OO design. Sometimes you have to code based on the constraints of your environment.
While you can achieve some degree of functional programming in C#, you'd probably want to just "bite the bullet" and move to F#. F# is a wholly a functional language, and you enjoy all of the benefits (and curses) of such a language. Functional programming tends to warrant a different way of thinking about your code, though. I haven't really coded in F#, but I believe there is a some degree of OO that you can achieve in it also.
I think you might be referring to "procedural" when you say "functional". (Maybe not.) While you can do each (to some degree) in C#, C#'s real power is in OO programming, as you've observed. In my shop, we have a lot of batch jobs that were ported over from a mainframe system. These kinds of applications tend to be more procedural in nature, with some OO sprinkled in for sugar at times. But with the deadlines we get on these conversions, we don't get a lot of time to perfect a nice OO design. Sometimes you have to code based on the constraints of your environment.
While you can achieve some degree of functional programming in C#, you'd probably want to just "bite the bullet" and move to F#. F# is a wholly a functional language, and you enjoy all of the benefits (and curses) of such a language. Functional programming tends to warrant a different way of thinking about your code, though. I haven't really coded in F#, but I believe there is a some degree of OO that you can achieve in it also.
Kaufmed,
I meant ebook :-). Yes, I probably meant Procedural. Most of my background has been in assembler, (machine and process control). I used a state machine approach most of the time to alter the processes. I like the State aspects, the ability to create my own types, refer to them and the partitioning of each module(Object). I believe all my future code can be OO and benefit in development, expansion and maintainability. I am working on all new code so I have the opportunity to use all OO.
Regards
Sam
I meant ebook :-). Yes, I probably meant Procedural. Most of my background has been in assembler, (machine and process control). I used a state machine approach most of the time to alter the processes. I like the State aspects, the ability to create my own types, refer to them and the partitioning of each module(Object). I believe all my future code can be OO and benefit in development, expansion and maintainability. I am working on all new code so I have the opportunity to use all OO.
Regards
Sam
You'll definitely want to read up on design patterns in OO programming. Lot's of people have spent lots of years crafting solutions to problems, and you can benefit from their work by knowing what they came up with. For instance, there is the State design pattern that you can write in OO.
I've personally acquired the Head First Design Patterns book, and found it very straight-forward in its presentation of the concepts. It's kind of a quirky/funky book, so it's not for everyone, but you may find it easier to read than something like the Gang of Four's book; maybe not. Also, the Head First book is written with Java examples, but the syntax that Java uses is very similar to C#, so it shouldn't be a strain to imagine the C# version of the code presented in the book.
I've personally acquired the Head First Design Patterns book, and found it very straight-forward in its presentation of the concepts. It's kind of a quirky/funky book, so it's not for everyone, but you may find it easier to read than something like the Gang of Four's book; maybe not. Also, the Head First book is written with Java examples, but the syntax that Java uses is very similar to C#, so it shouldn't be a strain to imagine the C# version of the code presented in the book.
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
All Courses
From novice to tech pro — start learning today.
The thing about static members is that they are really a kind of global (or shared) entity in your code. Since ASP.NET (or more appropriately, IIS) is a threaded environment, the problem you encounter with static resources is synchronizing thread access. Protecting shared resources that can be mutated from multiple threads is the inherent danger that you have to code for. If you merely have static methods which do not access shared data in your application, then you don't have to worry about thread synchronization. As an example, the Math class has numerous static methods that I can call in code. Any of those methods can be called from any thread in my application, because none of those methods access some shared piece of data in the application (or internally to the class itself). If you design a class in such a way, then you should have that same guarantee.
It appears that you've got some static methods declared in your class. These methods are not associated to any particular instance; rather they belong to the class itself. As such, there is only one instance of these methods, and using them does not cause a new instance of the class to be created.
Unit tests.
That depends on what your static methods are doing/touching.
Having one place to update a particular item in code is always something you want to strive for. Just be careful with having too much inheritance. Having a base page is probably fine, but having 7 layers of base page is a recipe for unmaintainable code also. Just give careful thought to your design.
See above.
I don't see why this is an issue. Session exists per user, and it's hydrated in your code based off either a cookie that the client sends back, or in the case of cookie-less sessions, an identifier in the incoming URL. You get a propery in your Page named "Session" that can be accessed from anywhere within the page. So as long as you come up with a meaningful naming scheme for the keys that make up your session, then session access should be quite trivial.