none
Crear una propiedad estatica a partir de una clase hace que todos los miembros de esa clase sean astaticas? RRS feed

  • Pregunta

  • Tengo una clase "A" con métodos no estáticos que gestiona la conexión a la base de datos. Esta clase inserta, busca, modifica, borra registros de las tablas, pero he creado otra clase "B" usando la clase A como estatica de esta forma:

    Capa de datos:

     public class A
        {
            public A(string conexion){}

            public void autenticar(){}

            public void insertar(){}

            public void buscar(){}
        }

      public class B
        {
            public static A a;

            public static void conectar() {
                a = new A("stringconexion");
                a.autenticar();
            }
        }

    Capa lógica de negocio:

                

      class C
        {
            public void ingresar() {
                B.conectar();
                B.a.insertar();

            }
        }

    Al final lo llamamos 

        static void Main(string[] args)
            {
                C c= new C();
                c.ingresar();
            }

    Leyendo encontré que no es buena practica tener las conexiones a base de datos estáticas.

    Alguien me escriba si esto esta mal y si es así cual es la mejor practica cuando se usan diferentes capas.

    Gracias de antemano. 


    Better late than never...


    • Editado Robertodlm domingo, 1 de mayo de 2016 1:22 Mal elaboración del ejemplo
    sábado, 30 de abril de 2016 19:43

Todas las respuestas

  • Si llama a B.A.<cualquier cosa> antes de instanciar A (que lo veo en el método conectar() de la clase B), entonces tendrá una excepción de tipo NullReferenceException.

    Si su idea es mantener una conexión a la base de datos, eso ya lo hace ADO.net.  ADO.net tiene lo que se llama connection pooling, y ya hace esto por usted.  Por lo tanto no es necesario hacerlo otra vez.

    No sé qué motor de base de datos está usando, pero hasta donde sé el concepto aplica para todos.


    Jose R. MCP
    Code Samples

    sábado, 30 de abril de 2016 23:56
  • Tenias razón, he modificado el código para que sea mejor entendido. Vuelva a chequear. Mi pregunta es:

    Al declarar la clase A estática en B, se vuelven todos los miembros de A estáticos?

    Según lecturas no es recomendable que la clase conexión quede estática.

    Luego de llamar el método: B.conectar();, puedo invocar desde cualquier clase los metodos de la clase A de la siguiente manera: B.a.insertar()  

    Como estoy trabajando en capas necesito la mejor forma de manejar esto. Puede que tenga que hacer new en cada metodo de cada clase que necesite manejar la base de datos o, si no es ningun problema de esta forma solo llamar la clase conexion. 

    Gracias por su pronta respuesta.


    Better late than never...

    domingo, 1 de mayo de 2016 1:30
  • La respuesta es No, los miembros de la clase A nunca serán estáticos a menos que se declaren estáticos con static y justamente por eso le dará un NullReferenceException si trata de acceder algo de A sin haber instanciado A.

    Nuevamente le repito que ya existe connection pooling en ADO.net.  Comprendo su interés en tener un singleton de la clase de conexión, pero no hace falta debido al pooling.

    Lo que le recomiendo es buscar un mejor diseño de forma de que no sea problemático tener una nueva instancia de la clase de conexión.

    Yo en mis diseños nunca tengo un singleton de la clase de conexión, sobre todo porque si la conexión es para SQL Server y se usa autenticación Windows con personificación ASP.net, entonces usar un singleton de la conexión usará un usuario de Windows diferente y por lo tanto podría incurrir en problemas de seguridad.


    Jose R. MCP
    Code Samples

    domingo, 1 de mayo de 2016 1:43
  • Muchas gracias. Es una aplicación desktop que será usada en red. Leeré sobre el "connection pooling en ADO.net"

    Voy a desistir del singleton y crearé la instancia de la clase conexión en cada constructor de la clase que lo requiera. 

    Muchas gracias. Su respuesta me satisface.

     

    Better late than never...

    domingo, 1 de mayo de 2016 1:57