Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Are there any reasons why static classes in Asp.Net can lead to a security threat?
Do not objects just live in current session ?
Thank you!
Objects live in a so called AppPool in the IIS. As long as that is not recycled, objects with static lifetime will be available. As one cannot reliably know when recycling happens, having static variables is a bad idea either way. Using them to hold data between calls or assuming they will not hold data between calls is both equally dangerous.
That said, if your static class does not hold data and only consists of methods, that's perfectly fine.
Static class has no instance, and consequently you should not be keeping any state of any object in side them. So theoretically it shouldn't be an issue with the security of designed correctly.
Now static variables on the other side could cause security issue if used improperly.
For example if variable like isLoggedIn is static, once one person logs in, every other user is automatically logged in because the variable will be true for every instance of the class using it.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I Started Learning C# and it confuses me with term 'outsiders'. Are outsiders some unauthorized people to our code?
It is not C# jargon, but it refers to any entity that is not the object.
In this specific case, outsiders might be the factory that creates the player or other entities of the game.
In general you want to grant access to specified resources only to a selected few. This maintains the code cleaner (as you force using specific accesses you appositely designed) and ensures the flow is followed (imagine that when setting the score you also want to update other variables of Player, if someone modified the variable directly, the side effects would be bypassed).
The whole situation becomes even more critical when you are writing a library for others: you want to encapsulate the internal variables as much as possible and not allow others to have "free access" to everything, as they might tamper with important stuff.
Outsiders is any other code outside of this object. So when you set variable as private, only code in this object can change it. That way you force any other code outside this class to modify score only by calling setScore method, and not directly accessing it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Ok, this subject is probably done to death but I wanted to throw it out there to see what people thought of my approach.
I need to create a simple WinForms application that will consist of a handle of forms. There will be variables that I can stick into the app.config as they'll never really change. However there will be some variables that are pulled in from a database unique to the user thats logging in. It's these variables that I need to persist and make available to the rest of the application to drive appropriate business logic.
Based on other articles on StackOverflow my plan would be to use the singleton pattern with IoC. So first instantiating a class based on the singleton pattern which is hooked up to an interface. The instantiated object would then be passed into the constructer of other methods in program.cs where I'll arrange most of my objects. This should mean I can easily test and mock this and other classes (I think?).
I've seen there are two ways of creating a class based on the singleton pattern, one that is the 'classic' way of doing it but isn't thread safe. The other requires slightly more coding but would be thread safe. My WinForms project would be pretty simplistic and wouldn't require multiple operations running in the background. Just simple CRUD operations fired off from the UI. For ease, I thought I'd use the classic singleton (non-thread safe) approach. That said, is that a bad thing to do, even for the most simplest of WinForm apps?
If you're using .NET 4.0+, just use Lazy<T> class for your singletons. If you insist on not caring about thread safety (why though?), get => _value ?? (_value = GetValue()) is enough.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am developing a software in WPF c#. My software has multiple windows. I need to share a same instance of on object across multiple windows (I am using legacy code, so I can not make that object static). Is it a good practice to have a static class which will have variables that I need to share across multiple windows, so I can avoid passing them through a constructor. Thank you
You could either use a static class or you could inject all windows/view models with the same singleton instance. Note that this doesn't necessarily has to be a class that actually implements the singleton design pattern but you need to make sure that you inject the windows/view models with the very same instance.
The latter approach is the preferred one, mainly because a non-static shared class can implement an interface which enables you to easily replace the implementation with another one which in turn makes it a lot easier to unit test your classes.
So it is not, at least in the general case, really a good practice to use a global static class but this might still work in your specific scenario.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
When do I create a business service aka ConfigurationService.
When the logic in the service has access to a database or filesystem?
When is a class a service?
Is reading an xml file a ConfigurationReader and not ConfigurationService because it has no database access?
Generally I distinguish services from domain objects by the fact that they are stateless. They often (but not always) have access to sources of state (like databases or file systems), but they do not contain it themselves.
So, if ConfigurationReader reads the configuration from the passed xml, and then keeps that configuration in local variables, it's a domain object. If it reads the configuration, and returns the "parsed" configuration objects, then it's a service.
Like the above comment though, this is all semantics, and other people's definition will vary greatly.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 months ago.
Improve this question
Today I was asked why we cannot implement state management in Winforms applications like we do in web applications, and I did not know the answer.
Can someone explain why we cannot, or if we can, explain how it works at a high level?
[...] why we cannot implement state management in Winforms [...]
This is an incorrect statement. In fact, we implement session management in every Winforms application, and we are so habitual about doing it that we don't even realise we are doing it.
The very nature of a desktop application is that all the state information you need is available in process memory, and it remains available as long as your application is running.
For example, it you set the value of a string variable to "Hello World", it will retain its value as long as that variable is accessible. Unlike web applications, you don't have to do anything explicitly to retain it. So the correct question might be
Why don't we need to implement session management in a WinForms application?
although I would be stumped by the obviousness of answer.
We can implement state management in Winforms.
Assume you need to access a Winforms control value in another Winforms application by clicking a button on the first form. You can access them by:
declaring public class members and auto implemented properties in the second form.
Set the values of the second form's class members in the first form's button_click event
After step 2, run the code you want to run on button click.
So the class and its members can be used in achieving state management in Winforms application.