naming-conventions - pattern - data access object

Terminología de persistencia de objetos: ''repositorio'' vs. ''almacén'' vs. ''contexto'' vs. ''recuperador'' vs.(...)

Question

No estoy seguro de cómo nombrar las clases del almacén de datos al diseñar la capa de acceso a datos (DAL) de un programa.

(Por clase de almacén de datos , me refiero a una clase que es responsable de leer un objeto persistente en la memoria, o de persistir un objeto en memoria).

Parece razonable nombrar una clase de almacén de datos de acuerdo con dos cosas:

• qué tipo de objetos maneja;
• Si carga y / o persiste dichos objetos.

⇒ Una clase que carga objetos de Banana puede llamarse, por ejemplo, BananaSource .

No sé cómo abordar el segundo punto (es decir, el bit Source en el ejemplo). He visto diferentes nombres aparentemente utilizados para ese propósito:

• repositorio : esto suena muy general. ¿Esto denota algo de lectura / escritura accesible?
• tienda : esto suena como algo que potencialmente permite el acceso de escritura.
• contexto : suena muy abstracto. He visto esto con LINQ y los mapeadores objeto-relacionales (ORM).
  PS (varios meses más tarde): Esto es probablemente apropiado para contenedores que contienen objetos "activos" o supervisados ​​de otra manera (el patrón de Unidad de Trabajo viene a la mente).
• Retriever : suena como algo de solo lectura.
• fuente y sumidero : probablemente no sea apropiado para la persistencia de objetos; un mejor ajuste con los flujos de datos?
• lector / escritor : bastante claro en su intención, pero suena demasiado técnico para mí.

¿Son estos nombres arbitrarios, o hay significados / diferencias semánticas ampliamente aceptados detrás de cada uno? Más específicamente, me pregunto:

• ¿Qué nombres serían apropiados para los almacenes de datos de solo lectura?
• ¿Qué nombres serían apropiados para los almacenes de datos de solo escritura?
• ¿Qué nombres serían apropiados para la mayoría de los almacenes de datos de solo lectura que se actualizan ocasionalmente?
• ¿Qué nombres serían apropiados para la mayoría de los almacenes de datos de solo escritura que se leen ocasionalmente?
• ¿Un nombre se ajusta a todos los escenarios igualmente bien?

Answer 1

Como nadie ha respondido aún a la pregunta, publicaré lo que he decidido mientras tanto.

Solo para el registro, he decidido prácticamente llamar a la mayoría de los repositorios de clases del almacén de datos. Primero, parece ser el término más neutral y no técnico de la lista que sugerí, y parece estar bien en línea con el patrón del Repositorio .

En general, el "repositorio" parece encajar bien donde las interfaces de recuperación / persistencia de datos son algo similar a lo siguiente:

public interface IRepository<TResource, TId>
{
int Count { get; }
TResource GetById(TId id);
IEnumerable<TResource> GetManyBySomeCriteria(...);
TId Add(TResource resource);
void Remove(TId id);
void Remove(TResource resource);
...
}

Otro término que he decidido usar es proveedor , que prefiero a "repositorio" cada vez que se generan objetos sobre la marcha en lugar de ser recuperados de un almacén de persistencia, o cuando el acceso a un almacén de persistencia ocurre en una lectura pura -sólo manera. (La fábrica también sería apropiada, pero parece más técnica, y he decidido en contra de los términos técnicos para la mayoría de los usos).

PD: Ha pasado un tiempo desde que escribí esta respuesta, y he tenido varias oportunidades en el trabajo para revisar el código de otra persona. Por lo tanto, un término que he agregado a mi vocabulario es Servicio , que estoy reservando para los escenarios de SOA: podría publicar un FooService que esté respaldado por un repositorio o proveedor privado de Foo . El "servicio" es básicamente una capa delgada orientada al público por encima de esta que se ocupa de cosas como la autenticación, la autorización o la agregación / agrupación de DTO para una "fragmentación" adecuada de las respuestas del servicio.