Делать статический метод Связь (), что присоединяет к базе данных: хороший рисунок или нет?

У меня есть следующий класс с методом Conectar(), что то, что он делает, состоит в том, чтобы открывать связь в базу данных Firebird. Он делает все правильно, и потом к этому методу я это призываю с другого класса, который он получает в наследство от этой, делая один ConexionFB.Conexion().Open() чтобы открывать связь, и т.д.

Мое сомнение, - если я принес пользу помещая это как static или нет, так как это у меня не остается очень ясным. Метод это использовал для login веб-страницы.

public class ConexionFB
{
    private static FbConnectionStringBuilder parametros_conexion = new FbConnectionStringBuilder();
    private static FbConnection conexion = new FbConnection();

    protected static FbConnection Conectar()
    {
        parametros_conexion.DataSource = "localhost";
        parametros_conexion.Port = 3050;
        parametros_conexion.Database = @"C:\FirebirdDB\USUARIOS.FDB";
        parametros_conexion.UserID = "SYSDBA";
        parametros_conexion.Password = "masterkey";
        parametros_conexion.ServerType = FbServerType.Default;

        conexion = new FbConnection(parametros_conexion.ToString());

        return conexion;
    }
}
3
задан 06.01.2017, 22:16
0 ответов

Иметь метод Conectar как static, он не обязательно дьявол, хотя я не понимаю, почему это у тебя есть как protected, это мне не кажется правильным.

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

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

  • В зависимости от базы данных, смоги бросать в тебя исключения из-за того, что старается манипулировать несколькими result sets в то же время.
  • Ты можешь разлагать твои данные, если сделки 2 пользователей перемешиваются вместе.

Скорее, позволь, что каждый пользователь (трэд) открыл и закрыл связь как необходимость, идеально используя connection пул, чтобы приуменьшать цену "открытия" связи, хотя типичное состоит в том, чтобы это было сделано автоматически согласно connection string, который ты используешь (я не знаю, как оно функционирует с Firebird).

В твоем месте, мне restructuraría класс этой формы (он ощущается, что connection string да остается статический, как, это не проблема. Но переменная conexion в себе он остается eliminida класса):

public static class ConexionFB
{
    private static readonly string ConnectionString;

    static ConexionFB()
    {
        var parametros_conexion = new FbConnectionStringBuilder();
        parametros_conexion.DataSource = "localhost";
        parametros_conexion.Port = 3050;
        parametros_conexion.Database = @"C:\FirebirdDB\USUARIOS.FDB";
        parametros_conexion.UserID = "SYSDBA";
        parametros_conexion.Password = "masterkey";
        parametros_conexion.ServerType = FbServerType.Default;
        ConnectionString = parametros_conexion.ToString();
    }

    public static FbConnection Conectar()
    {
        return new FbConnection(ConnectionString);
    }
}

Пример, как использования этого:

using(var connexion = ConexionFB.Conectar())
{
    // ... usar conexión aquí...
}

Маленькое добавочное замечание: хотя я не знаю Firebird, я подозреваю, что это не была хорошая мысль использовать sysdba для связи. Звучи как, который ты используешь пользователь администратор со слишком многими разрешениями.

4
ответ дан 03.12.2019, 17:51
  • 1
    Стой, большое спасибо. Это помещения mé каждый protected я это сделал, потому что мой intenció n он состоял в том, чтобы использовать mé совсем Присоединять (), только в классе, который он получал в наследство от этой. –  07.01.2017, 03:02
  • 2
    И другая вещь, которую он дифференцирует, он должен использовать: using(var connexion = ConexionFB.Conectar()), чтобы не помещать using и создавать переменную без using? Прости, но я достаточно новый в этом –  07.01.2017, 03:11
  • 3
    Я передаю тебя к using (Instrucció n, Снабди ссылками C#) , чтобы читать по этому поводу. Кратко, он имеет общее с классами, которые осуществляют интерфейс IDisposable, которые я принимаю, - случай с классом FbConnection. В этих случаях, using он гарантирует тебе, что объект в cuestió n будешь освобождать Ваши ресурсы в конце блока (выполняя mé совсем Dispose()), aú n, когда оно последует за excepció n. Без using, писать có я говорю, что эквивалентный руке он довольно длинный. –  07.01.2017, 03:16
  • 4
    То, что делает Using, состоит в том, чтобы избавлять тебе tenes, который писать Try { } и Finally { " Dispose переменной conexion" } –  13.02.2017, 22:46
  • 5
    @sstan В случае, что aplicació n он был конторы podrí чтобы использовать переменную conexió n как static не? –  13.02.2017, 22:54

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

0
ответ дан 03.12.2019, 17:51
  • 1
    mé весь está костариканский он не заканчивается обязательно разделенными связями. –  06.01.2017, 22:05

Год 90%, ленивый синглтон, парал лас, основа данных, аль ленивый тенем "потокобезопасен" и распространяется без ошибок. Синглтон, синглтон, сингл-ха-ха-эс-си-с-эн-хе нингуна инстанськсья, созданная, как само собой разумеющееся, от первого лица, до сих пор не является обязательным, нет необходимости, manejando una única conexión. Habría que tener cuidado eso si, en cada operación que tengamos con BD de hacer connection.open y connection.close para mas seguridad.

открытый класс SingletonDB {

private static readonly Lazy<ExampleClass> _instance = new Lazy<ExampleClass>();

public static ExampleClass Instance { get { return _instance.Value; } }

private readonly SqlConnection _connection = new SqlConnection(ConfigurationManager.ConnectionStrings["DB_NAME"].ConnectionString);


public DataTable GetAll()
{

    DataTable auxDt = new DataTable();
    SqlDataAdapter auxDa = new SqlDataAdapter();
    SqlCommand auxCmd = new SqlCommand("SP_NAME", _connection);
    auxCmd.CommandType = CommandType.StoredProcedure;
    auxCmd.Parameters("PARAMETER_NAME", parameterValue, SqlDbType.BigInt);


    try
    {
        if (_connection.State == ConnectionState.Closed)
        {
            _connection.Open();
        }

        auxDa.SelectCommand = auxCmd;
        auxDa.Fill(auxDt);
        _connection.Close();
    }
    catch(Exception ex)
    {
        throw;
    }

    return auxDt;
}
0
ответ дан 03.12.2019, 17:51
  • 1
    Но, ¿ qué оно происходит, когда 2 клиента нуждаются в conexió n в то же время? –  13.02.2017, 13:35
  • 2
    Не ocurrirí ни во что, в самом деле это ú nica инстанция conexió n, в которую присоединяются N клиенты, из-за которого класс подхода к данным serí в tambí в singleton deberí схвати подтверждать состояние conexió n в том же классе, в котором ты соглашаешься, я оставляю пример có я говорю в другом отдельном ответе. –  13.02.2017, 19:19
  • 3
    Этот diseñ или он будет давать тебе ошибки в одной атмосфера мульти-нити. Если 2 клиента стараются использовать ту же conexió n в то же время ты можешь получать ошибки, потому что ты имеешь больше одного " resultset" открытый в то же время. Или хуже, если говорится о 2 клиентах осуществляя изменения в 2 отличных сделках, ты можешь получать ошибки или вводить изменения в transacció n спутанная возможно вызывая corrupció n данных. Использование singleton не приспособлено для связей баз данных. Каждый клиент должен мочь работать в conexió n независимый и aí slada demá s клиенты. –  13.02.2017, 20:05
  • 4
    Я думаю, что Lazy, не ли ошибаюсь я, делает locks, а следовательно это уверенно в окружении мультинити, segú n documentació n Microsoft. –  13.02.2017, 20:15
  • 5
    Одинокое использование Lazy гарантирует тебе, что все нити будут получать ту же conexió n без проблем. Но он не поставляет никакой garantí в на использовании счастья conexió n как только ты получаешь ее. Класс SqlConnection не был diseñ ada, чтобы делиться несколькими нитями, из-за того, что не приспособлено использования этого в singleton. Если ты продолжаешь соединение, verá s, что внизу говорит следующее относительно класса SqlConnection: не гарантирует себе, что члены инстанции были безопасными для субпроцессов. –  13.02.2017, 20:22

Теги

Похожие вопросы