¿El patrón DAO está obsoleto en Scala?

Question

Consideremos un ejemplo simple del patrón DAO. Deje Person es un objeto de valor y PersonDAO es el rasgo correspondiente, que proporciona métodos para almacenar/recuperar Person a/desde la base de datos.

trait PersonDAO { 
    def create(p:Person) 
    def find(id:Int) 
    def update(p:Person) 
    def delete(id:Int) 
}

Utilizamos este patrón (a diferencia de Active Record, por ejemplo), si queremos separar el dominio comercial y la lógica de persistencia.

¿Qué sucede si usamos another approach en su lugar? Crearemos PersonDatabaseAdapter

trait PersonDatabaseAdapter{ 
    def create 
    def retrieve(id:Int) 
    def update 
    def delete 
}

y conversión implícita de Person a ella.

implicit def toDatabaseAdapter(person:Person) = new PersonDatabaseAdapter { 
    def create = ... 
    def retrieve(id:Int) = ... 
    def update = ... 
    def delete = ... 
}

Ahora bien, si importamos estas conversiones, podemos escribir código de cliente para manipular Persons y almacenar/recuperar a/desde la base de datos de la siguiente manera:

val person1 = new Person 
... 
person1.create 
... 
val person2 = new Person 
... 
person2.retrieve(id) 
...

Este código es el Active Record pero el dominio comercial y la persistencia aún están separados.

¿Tiene sentido?

Answer 1

Bueno, no sé nada sobre los patrones "obsoletos". El patrón es un patrón y lo usas donde sea apropiado. Además, no sé si algún patrón debería estar obsoleto en un idioma a menos que el lenguaje lo implemente con la misma funcionalidad.

objeto de acceso a datos no es obsoleta, que yo sepa:

http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

http://en.wikipedia.org/wiki/Data_access_object

Answer 2

Me parece que todavía está utilizando el patrón DAO. Usted acaba de implementarlo de manera diferente.

De hecho, encontré esta pregunta porque estaba investigando si el patrón DAO está muerto en Java simple, dado el poder de Hibernate. Parece que la sesión de Hibernate es una implementación genérica de un DAO, definiendo operaciones tales como create, save, saveOrUpdate, y más.

En la práctica, he visto poco valor en el uso del patrón DAO. Cuando se utiliza Hibernate, las interfaces e implementaciones de DAO son envoltorios redundantes alrededor de modismos Hibernate Session de una sola línea, por ejemplo, getSession(). Update (...);

Lo que termina con interfaces duplicadas: una interfaz de servicio que redefine todos los métodos en la interfaz DAO más algunos otros implementados en términos de esos.

Parece que Spring + Hibernate ha reducido la lógica de persistencia casi a una trivialidad. La portabilidad tecnológica de persistencia NO es necesaria en casi todas las aplicaciones. Hibernate ya le ofrece portabilidad de base de datos. Claro, DAO le daría la posibilidad de cambiar de Hibernate a Toplink, pero en la práctica, uno nunca haría esto. Las tecnologías de persistencia ya son abstracciones con fugas y las aplicaciones se construyen para hacer frente a este hecho, como cargar un proxy para establecer asociaciones frente a realizar un hit de base de datos, lo que necesariamente las vincula a la tecnología de persistencia.Sin embargo, estar conectado a Hibernate no es tan malo, ya que hace todo lo posible para salir del camino (sin excepciones comprobadas a la JDBC y otras tonterías).

En resumen, creo que su implementación Scala del patrón DAO está bien, aunque probablemente podría crear una mezcla completamente genérica que daría operaciones CRUD básicas a cualquier entidad (la mayoría de los desarrolladores competentes implementan un "DAO genérico") clase base en Java, también). ¿Es eso lo que hace Active Record?

/Fin de las notas al azar/

Answer 3

Creo que su PersonDatabaseAdapter muta Person en su método retrieve(id: Int). Por lo tanto, este patrón obliga a los objetos de su dominio a ser mutables, mientras que la comunidad de Scala parece favorecer la inmutabilidad debido a la naturaleza funcional (o características) del lenguaje.

De lo contrario, creo que el patrón DAO todavía tiene las mismas ventajas y desventajas (enumeradas here) en Scala que en Java.

Answer 4

Actualmente, veo que el patrón Repositorio es bastante popular, especialmente porque su terminología hace que parezca que se trata de colecciones.