Terminología de persistencia de objetos: 'repositorio' frente a 'almacenar' frente a 'contexto' frente a 'retriever' vs. (...)

Question

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

(Por de datos de clase del almacén, me refiero a una clase que se encarga de leer un objeto persistido hasta la memoria, o que persista un objeto en memoria.)

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

• qué tipos de objetos maneja;
• si carga y/o persiste tales objetos.

⇒ Una clase que carga Banana objetos se puede llamar, p. BananaSource.

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

• repositorio: esto suena muy general. ¿Esto denota algo accesible para lectura/escritura?
• tienda: esto suena como algo que potencialmente permite el acceso de escritura.
• contexto: suena muy abstracto. Lo he visto con LINQ y mapeadores relacionales de objetos (ORM).
  P.S. (varios meses después): Esto es probablemente apropiado para contenedores que contienen objetos "activos" u otros objetos supervisados ​​(el patrón de la Unidad de Trabajo viene a la mente).
• retriever: suena como algo de solo lectura.
• fuente & sink: probablemente no es apropiado para la persistencia del objeto; un mejor ajuste con flujos de datos?
• lector/escritor: bastante claro en su intención, pero suena demasiado técnico para mí.

¿Son estos nombres arbitrarios, o existen significados ampliamente aceptados/diferencias semánticas 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 almacenes de datos de solo escritura?
• ¿Qué nombres serían apropiados para los almacenes de datos de solo lectura que se actualizan ocasionalmente?
• ¿Qué nombres serían apropiados para la mayoría de las tiendas de datos solo de escritura que se leen ocasionalmente?
• ¿Un nombre se ajusta a todos los escenarios igualmente bien?

Answer 1

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

Sólo para que conste, más o menos he decidido llamar a la mayoría de las clases de datos del almacén repositorios. En primer lugar, parece ser el término más neutral, no técnico de la lista que sugerí, y parece estar en consonancia con el Repository pattern.

En general, "depósito" parece encajar bien en las interfaces de recuperación de datos/persistencia 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 sobre el uso es proveedor de, que prefiero al "repositorio" siempre que los objetos se generan sobre la marcha en lugar de recuperarlos de un almacén de persistencia, o cuando el acceso a un almacén de persistencia ocurre de una manera puramente de solo lectura. (fábrica También sería apropiado, pero suena más técnico, y he decidido en contra de los términos técnicos para la mayoría de usos.)

PS: algún tiempo ha pasado desde que escribir esta respuesta, y no tengo Tuve varias oportunidades en el trabajo para revisar el código de otra persona. Un término que agregué a mi vocabulario es Servicio, que reservé para escenarios SOA: podría publicar un FooService respaldado por un repositorio o proveedor privado Foo. El "servicio" es básicamente una delgada capa pública que se encarga de cosas como la autenticación, autorización o adición/dosificación de DTO para el correcto "chunkiness" de las respuestas del servicio.