Bank connection object: should I have only one for the whole system or one instance per class?

0

What is the best practice: to have only one point (Singleton) that returns the connections to the database or to create an instance of the connection for each object?

My system accesses multiple banks and so I created a AcessoBanco class that, from a .INI file, creates the necessary connections.

My project was using a static class (Singleton) that returned the database connections I need. I started having sporadic exceptions because my system is multi-thread . I have created locks for exclusive access to the properties that expose the connections, but I was in doubt, this is a good practice.

I imagine that if each DAO creates its own instance of the connections, this competition problem would be eliminated. I'll give some examples

Using a Singleton

public class Repositorio1
{
    public Repositorio1(string caminhoArquivoINI)
    {
        AcessoBanco.Configurar(caminhoArquivoINI); // Singleton único que cria as conexões (gerava problemas de concorrencia resolvido com locks)

        // Depois de configurado basta usar AcessoBanco.ObterConexao() em qualquer ponto do código para obter uma conexão 
    }
}

Using one instance per object

public class Repositorio2
{
    public AcessoBanco Conexoes { get; set; }

    public Repositorio2(string caminhoArquivoINI)
    {
        Conexoes = new AcessoBanco(caminhoArquivoINI); // Utilizando uma instancia por objeto. Isso tem que ser feito em toda classe que deseja acessar o banco.
    }
}
    
asked by anonymous 23.11.2018 / 20:23

1 answer

0

What's best is always complicated to say without a specific context.

People find that creating connections is expensive and that there will be a complicated process. At least that's what I imagine, I'm not in their minds. I know that many people use this premise, but it may be that they are just copying what they saw wrong there.

The fact is that the connection object is a pool , it gives you a connection according to your need and knows how to manage the connections, and is an object well thought out and developed by people who understand how do this correctly. Everything works perfectly, with performance in a simplified way.

It is even possible to create a simple abstraction to simplify something specific, but to create a Singleton, or a substitute for the connection as I see in almost all the codes that the personnel put here, is absurd, antipattern . It is a person who understands little or nothing of the subject trying to create something certainly worse for little or no gain.

So the two cases presented seem to be wrong. Of course, I did not see this class AcessoBanco , but almost everyone does it wrong.

These reported issues probably occur because you are implementing it wrong. And the correct thing is to implement none of this. It begins to create new problems to solve the problems that should not even exist. If such an abstraction were required for any application .NET would provide. Never implement anything that you can not justify with propriety.

I believe the problem occurs because people try to create design patterns without even understanding what problem it is solving, this includes DAO or repository, it is usually quite complicated to do right, and almost always does not give the benefit that person think it will, it's just doing what "everybody" is doing, not understanding how to do it.

By the comment it does not make sense to have a Singleton, after all it has different connections, it is plural and not singular.

    
23.11.2018 / 21:18