Ruby on Rails with Repository Pattern?

Question

Después de trabajar con ASP.Net MVC, tengo que pensar en Rails. Trabajé con Rails anteriormente, pero estoy un poco oxidado. Los tutoriales ASP.Net MVC recomiendan ocultar la implementación de la capa de datos con el patrón de repositorio. Esto permite una inyección de dependencia más sencilla para las pruebas unitarias y un agradable desacoplamiento del controlador de la implementación del modelo.

Recuerdo los controladores de Rails que usan objetos Active Record directamente, y las pruebas de unidades usando bases de datos de prueba que se pueden configurar y desmontar con facilidad. Eso resuelve la necesidad de cambiar para pruebas unitarias, pero aún parece una mala idea tener tanto código ActiveRecord expuesto en el controlador.

Así que mi pregunta es, ¿cuál es la última mejor práctica aquí? ¿Se siguen utilizando bases de datos reales (sin burlarse) para las pruebas unitarias? ¿Los desarrolladores de Do Rails llaman a ActiveRecord directamente, o una abstracción?

Answer 1

¿Realmente ActiveRecord constituye realmente la "capa de datos", me pregunto? Después de todo, su propósito es abstraer (en una medida bastante razonable) el almacenamiento de interacción real. Si tengo un modelo que hereda de ActiveRecord::Base y hago referencia a ese modelo en un controlador, ¿realmente estoy interactuando con la capa de datos?

Mirando una breve descripción de Repository Pattern Diría que los métodos del find_by_ ya le están dando mucho de lo que describe, lo cual es bueno, ¿no? OK, la capa de abstracción tiene goteras (podría decirse que es más "pragmático") en cuanto a que podemos acercarnos mucho más al metal si es necesario, y find_by_sql, por ejemplo, hará que resulte obvio que estamos tratando con un entorno relacional base de datos de algún tipo.

Recomendaría nunca (o tal vez debería decir "rara vez y no sin justificación extrema" - siempre es complicado usar absolutos) poner código en los controladores que hace posible inferir la plataforma de datos que se utiliza. Todo debe ser introducido en los modelos: named_scope puede ser muy útil aquí. Para resultados complejos, considere el uso de objetos de "presentación" como la interfaz (Struct y mi favorito personal OpenStruct puede ser muy útil aquí).

Si bien ActiveRecord es de facto estándar, dado que se instala con Rails, no es el único juego de la ciudad. Para bases de datos no son de SQL, es necesario algo diferente, pero incluso en el dominio de SQL hay DataMapper (es que en base a la eponymous PoEAA pattern?)

En Rails 3.0 que va a ser mucho más fácil pick and choose components como el ORM como Yehuda y los chicos se deshacen y limpian las interfaces.

Answer 2

Mi experiencia ha sido que Ruby on Rails integra ActiveRecord con tanta fuerza (en la mayoría de los casos, puede llegar a ser casi completamente transparente) que los desarrolladores a menudo lo usan sin ningún tipo de abstracción.

Lo que hay que recordar es que el patrón de repositorio y el patrón de registro activo se sugirieron en Patterns of Enterprise Architecture by Martin Fowler (que, si aún no lo ha leído ... debería hacerlo). Active Record está estrechamente integrado en Rails. Microsoft .NET no lo vincula con un patrón ... por lo que la mayoría de los desarrolladores adoptaron el patrón Repositorio.

Answer 3

Las convenciones de Folllowing Rails siempre conducen por la ruta de los recuerdos menos dolorosos, por lo que se recomienda.

Dependiendo de su definición de "real" ... Para pruebas unitarias he visto que las personas tienden a usar el mismo esquema de datos que su sitio principal, y sembrar la base de datos antes de ejecutar las pruebas/durante las pruebas (usando Factory Girl, Machinist o plain ol 'fixtures) y luego las pruebas se ejecutan en base a esos datos.

Los desarrolladores de Rails llaman a ActiveRecord directamente en esta información, como en el mundo real.

Answer 4

Se supone que los controladores acceden a modelos en MVC. Rails se trata de evitar algunas de las abstracciones innecesarias que caracterizan el mundo empresarial.

Answer 5

Puede hacerlo de cualquier manera. En la mayoría de los casos, las pruebas funcionales de Rails se escriben para llegar hasta la base de datos, donde los datos se completan a partir de los dispositivos, como usted describe.

Pero no es raro para burlarse de las llamadas capas de servicios, por ejemplo:

User.expects(:find_by_id).with("1").returns(u); 
get :show, :id=>"1" 

... o algo por el estilo. De hecho, hago esto todo el tiempo teniendo el control del objeto modelo (o simulando eso también).