¿Cómo debo encapsular el acceso a la base de datos?

7

¿Cuáles son algunos ejemplos de buenas estructuras de clase utilizadas para administrar el acceso a la base de datos? Soy un fanático de la encapsulación de clase y preferiría que los contenedores (por ejemplo, car) no realicen tareas de base de datos.

También me gustaría tener la posibilidad de colocar fácilmente cosas como un caché de base de datos en el futuro.

A menudo tomo el patrón de clases de contenedor, completo con captadores y configuradores para la validación y el acceso a la base de datos realizado por una sola clase de singleton. Dicho esto, a menudo esto se mezcla entre los dos y se vuelve bastante confuso.

Lo siento si mi pregunta es difícil de entender; No estoy absolutamente seguro de los términos relativos a las bases de datos. No dude en pedir una aclaración si es necesario.

    
pregunta Will03uk 12.07.2012 - 00:09

3 respuestas

9

Prefiero el Patrón de repositorio para encapsular el acceso a los datos. En pocas palabras, el repositorio es responsable de cargar todos los datos necesarios para un objeto específico. Digamos que tienes un objeto Car, como en tu ejemplo. Pero todos los atributos para el automóvil, marca, modelo, año, propietarios, características (reproductor de CD, 4wd, etc.) se almacenan en varias tablas en toda la base de datos. El repositorio determina cómo cargar y guardar los datos. Si se necesitan múltiples consultas más pequeñas, está bien, pero solo el patrón del repositorio debe saberlo. La capa de servicio que invoca el repositorio solo necesita saber qué repositorio invocar.

Luego se puede combinar con el patrón de unidad de trabajo . Entonces, en su ejemplo, la capa de servicio diría que necesita cargar una entidad de automóvil, tiene algún tipo de identificador único y envía ese identificador al repositorio. El repositorio devuelve la entidad coche. Algún otro código manipula la entidad del automóvil y la envía de vuelta al repositorio para que se pueda guardar.

Si realmente quiere hacer todo lo posible, la capa de repositorio solo expondría las interfaces, como ICarRepository. El repositorio contendría una factory que la capa de servicio usaría para obtener la interfaz ICarRepository. Todo el acceso a la base de datos estaría oculto detrás de una interfaz, lo que hace que las pruebas unitarias sean mucho más fáciles.

    
respondido por el bwalk2895 12.07.2012 - 04:07
6

He utilizado el Patrón de estrategia para encapsular el acceso a los datos. Este patrón le permite ocultar el tipo de almacenamiento que está utilizando detrás de una interfaz común. En la interfaz, defina sus métodos de acceso a los datos sin tener en cuenta el tipo de almacenamiento (archivo, base de datos, web). Luego, para su elección de almacenamiento actual, en una clase que tenga en cuenta la interfaz de la estrategia, implemente los detalles de acceso a los datos. De esta manera, a su aplicación no le importa la fuente de datos que está utilizando.

También puede crear una capa de servicio que use la instancia de la estrategia de almacenamiento de datos actual para definir más detalles específicos de la aplicación en lugar de mezclar el acceso a los datos y la lógica empresarial.

    
respondido por el Mike L. 12.07.2012 - 00:28
1

Este es un ejemplo de patrón de base de datos de fábrica;

using System.Reflection;
using System.Configuration;

public sealed class DatabaseFactory
{
    public static DatabaseFactorySectionHandler sectionHandler = (DatabaseFactorySectionHandler)ConfigurationManager.GetSection("DatabaseFactoryConfiguration");

    private DatabaseFactory() { }

    public static Database CreateDatabase()
    {
        // Verify a DatabaseFactoryConfiguration line exists in the web.config.
        if (sectionHandler.Name.Length == 0)
        {
            throw new Exception("Database name not defined in DatabaseFactoryConfiguration section of web.config.");
        }

        try
        {
            // Find the class
            Type database = Type.GetType(sectionHandler.Name);

            // Get it's constructor
            ConstructorInfo constructor = database.GetConstructor(new Type[] { });

            // Invoke it's constructor, which returns an instance.
            Database createdObject = (Database)constructor.Invoke(null);

            // Initialize the connection string property for the database.
            createdObject.connectionString = sectionHandler.ConnectionString;

            // Pass back the instance as a Database
            return createdObject;
        }
        catch (Exception excep)
        {
            throw new Exception("Error instantiating database " + sectionHandler.Name + ". " + excep.Message);
        }
    }
}
    
respondido por el theclai 12.07.2012 - 05:20

Lea otras preguntas en las etiquetas

Comentarios Recientes

Las restricciones en la solución SOLR ocultan uno de los principales problemas que enfrentan los administradores: acceso distribuido. Se trata principalmente de ser responsable. El acceso a la base de datos solo se puede aprobar una vez (por usuario en este ejemplo). Por ejemplo, este sistema no permite la entrada arbitraria en su comando DELETE, ni es lo suficientemente inteligente como para confiar en las contraseñas. Las cosas parecen estar bien, ¿hay algo más que podamos hacer? Sí, también hay algunos errores:... Lee mas