Статические методы в классе - хорошо в этой ситуации?

Question

Привет всем - у меня есть приложение, в котором я аутентифицирую пользователя. Они передают имя пользователя и пароль. Я передаю имя пользователя и пароль классу, который имеет статический метод. Например, я вызываю метод с подписью ниже:

public class Security
{
public static bool Security.Member_Authenticate (string username, string password) 
{ //do stuff}
}

Если у меня будет 1000 человек, поражающих это одновременно, у меня будут какие-нибудь проблемы с возвратом метода, проникающего в других? Я имею в виду, что поскольку методы являются статическими, будут ли проблемы с тем, что человек проходит проверку подлинности, тогда как на самом деле это не должно быть, но человек до того, как он прошел успешную проверку подлинности, ASP.Net возвращает несоответствующий результат из-за статичности метода? Я читал о проблемах со статическими свойствами по сравнению с viewstate, но я немного запутался в статических методах. Если это плохой способ сделать это, какой предпочтительный способ?

Answer 1

Этого не произойдет. Когда метод является Статическим (или Shared в VB.NET), тогда вы в безопасности, пока метод не полагается на что-либо, кроме входных данных, для выяснения чего-либо. Пока вы не изменяете какие-либо публичные переменные или объекты из других источников, все в порядке.

Answer 2

Статический метод хорош, если он не использует постоянные данные между последовательными вызовами. Я предполагаю, что ваш метод просто выполняет запрос к базе данных и возвращает истину / ложь на основе этого.

В этом сценарии я думаю, что статический метод должен работать без проблем, независимо от того, сколько вы обращаетесь к нему.

Answer 3

ASP.net использует все виды пула потоков под капотом, что может сделать статические методы и поля рискованными.

Однако вы можете избежать большинства проблем с многопоточностью статическим методом, используя в этом методе только локальные переменные. Таким образом, каждый поток (пользователь) будет иметь свою собственную копию в памяти всех используемых переменных.

Если вы используете переменные с более высокой областью действия, убедитесь, что все они имеют доступ к потокам.

Answer 4

Бросать исключения - не очень хорошая практика, поскольку во время выполнения .net создается дополнительная инфраструктура для их перехвата. Чтобы убедиться в этом, создайте класс и заполните его некоторыми случайными значениями, используя цикл. Сделайте цикл итерацией для большого счетчика, например, 10000. Запишите время, необходимое для создания списка. Теперь заключите создание экземпляра в блок try..catch и запишите время. Теперь вы можете увидеть исключительно большую разницу.

* 1003 например *

for(int i=0; i<10000; i++){
     Employee emp = new Employee();
     emp.Name = "Random Name" + i.ToString();
}

Versus

for(int i=0; i<10000; i++){
     try{
          Employee emp = new Employee();
          emp.Name = "Random Name" + i.ToString();
     }catch{}
}

Хотя не существует фиксированного решения, генерировать ли исключение или нет, лучше всего создавать альтернативные потоки в вашей программе и обрабатывать каждое условие с правильными возвращаемыми значениями. Исключения следует бросать только тогда, когда ситуация может быть оправдана как исключительная.

Answer 5

Хотя я вижу ценность статического метода в отношении воспринимаемого прироста производительности, я полагаю, что реальная проблема здесь заключается в том, стоят ли приросты (и риски) стоимости обслуживания и слабости безопасности, которую вы потенциально можете создать. Я считаю, что большинство людей будут предупреждать вас об отсутствии публичного метода, который принимает учетные данные пользователя и возвращает успех или неудачу. Это потенциально обеспечивает легкий метод для взлома.

Итак, моя точка зрения философская. В противном случае, я согласен с другими, которые указали, что ограничение кода для использования локальных переменных должно гарантировать, что у вас не будет никаких проблем с побочными эффектами из-за одновременного доступа к методу, даже в разных потоках, т. Е. Если вы вызываете метод в теме ThreadPool.

Answer 6

Почему у вас нет класса пользователя с именем пользователя и паролем и метода, который называется authenticate?

Answer 7

Может быть, лучше использовать public static void Authenticate(string, string), который выдает исключение, если что-то идет не так (return false в оригинальном методе)?

Это хороший стиль .NET. Возвращаемый тип булевой функции - это стиль C. Он устарел.