Definir capa de acceso a datos

Question

Parece que todo el mundo sabe que se supone que debe haber una distinción clara entre la GUI, la lógica de negocios y el acceso a los datos. Recientemente hablé con un programador que se jactaba de tener siempre una capa de acceso a datos limpia. Miré este código, y resulta que su capa de acceso a datos es solo una pequeña clase que incluye algunos métodos SQL (como ExecuteNonQuery y ExecuteReader). Resulta que en su código ASP.NET detrás de las páginas, tiene un montón de código SQL codificado en la página_carga y otros eventos. Pero él jura que está usando una capa de acceso a datos.

Por lo tanto, arrojo la pregunta. ¿Cómo definirías una capa de acceso a datos?

Answer 1

Lo que su colega está hablando no es un DAL por la mayoría de los cálculos de la gente. El DAL debe encapsular cualquier llamada a la base de datos, ya sea que se realice mediante SQL dinámico, procesos almacenados o un ORM con algo así como IRepository. Sus páginas web nunca deben contener SQL o lógica de negocios o de lo contrario se convierte en pesadilla de mantenimiento.

Answer 2

Un "recuadro negro" que contiene sus datos. Si el usuario le importa/puede decir que hay un DB ahí atrás (aparte de por consideración), no es en lo que estoy pensando

Answer 3

Personalmente defino el DAL como donde las interacciones entre mi aplicación y la base de datos existen . Entonces puedo tener una capa empresarial que interactúe con el DAL para permitir las operaciones CRUD.

EG Puedo tener un método ModelClass.LoadAll() que interactuaría con el DAL, que buscaría los datos y ModelClass utilizaría esos datos de la forma que lo necesitara.

Prefiero mantener el DAL lo más liviano posible, pero algunas otras personas prefieren el otro camino donde ocurre el llenado de los datos del modelo en el DAL.

Answer 4

Además de lo que han dicho los demás, generalmente considero que es el lugar para abstraer cómo se almacenan sus datos. Una capa de acceso a datos realmente buena debería permitirle intercambiar Oracle, SQL Server, Access, un archivo de texto plano, XML o lo que desee, y hacerlo sería transparente para las otras capas de aplicaciones. En otras palabras, el contrato entre la capa de acceso a datos y otras capas debe definirse de una manera independiente de la base de datos.

Answer 5

Un ejemplo muy simple para .NET sería el siguiente.

Si tienen dos clases: CiertaPágina (que es una página ASP.NET) y DataService (que es un viejo y simple clase C#)

Si CiertaPágina siempre llama a DataService para leer/escribir datos a continuación, tener una capa de acceso a datos. SomePage no contendrá ningún SQL o referencias a las clases System.Data.SqlClient.

Pero SomePage puede usar DataSets u objetos comerciales que se pasan desde y hacia la clase DataService.

Answer 6

Una capa de acceso a datos tiene acceso a los datos, y nada más.

Answer 7

He encontrado este artículo sobre la creación de un DAL:

http://www.simple-talk.com/dotnet/.net-framework/.net-application-architecture-the-data-access-layer/

Answer 8

me gustaría compartir este diseño de recuperador de datos (sólo lectura) capa.

Claves para la arquitectura:

• La idea es crear un objeto que es casi Singleton (explicado más adelante) que consiste en almacenar datos que se recuperan con métodos get - por debajo de lo llamo el DRO (DataRetrieverObject).
• Debe ser fácil para el objeto del cliente llegar al DRO.
• Debe ser fácil mantener las clases.

La estructura se basa en una construcción de tres pasos.

1. utilizar un DataRetrieverFactory que tienen métodos estáticos (sobrecargados), uno para cada tabla que necesita. Use la sobrecarga para hacer coincidir diferentes tipos de teclas. El método devolverá un DRO.

2. El DataRetrieverFactory delega el trabajo de construcción en una segunda clase <TableNameAndKey>DR que creará el DRO real.

3. En el <TableNameAndKey>DR tenemos una lista estática de punteros a DRO, haga un bucle en la lista para ver si ya tiene un DRO con la clave específica.

   3.1. Si encuentra un DRO - comprobar si está bien (lo que significa:

   • no debería ser "viejo",
   • que debe pertenecer a una sesión de gestión,
   • etc.)

   3.1.1. Si el DRO está bien, entonces regrese el DRO.

   3.1.2. Si el DRO no es correcto, elimine el objeto (y su puntero) y cree un nuevo DRO con datos de la base de datos. Guarde el puntero en la lista.

   3.2. Si no aparece ningún hit en la lista de punteros, creamos un nuevo DRO con datos de la base de datos y almacenamos el puntero en la lista estática.

Usando esta técnica se puede volver a utilizar el visualizador en función de la necesidad, sin embargo, la clase no se Singleton ya que se les permite tener un montón de instancias de la clase.