División de acceso a los datos de la clase en el lector y el escritor o combinarlos?

Question

Esto podría ser en la "discussy", pero realmente me gustaría escuchar su punto de vista sobre esto.

Anteriormente he escrito a menudo clases de acceso a datos que maneja tanto la lectura y la escritura, que a menudo condujo a los pobres de nomenclatura, como FooIoHandler etc.La regla general de que las clases que son difíciles de nombre probablemente están mal diseñadas sugiere que esta no es una buena solución.

Así, hace poco he comenzado a dividir los datos de acceso en FooWriter y FooReader, lo que conduce a más bonito nombres y le da más flexibilidad, pero al mismo tiempo me gusta mantener todo junto, si las clases no son grandes.

Es un lector/escritor de la separación de un mejor diseño, o debo combinarlos?Si debo combinarlos, ¿qué diablos debo nombre de la clase?

Gracias /Erik

Answer 1

ORM podría ser su mejor solución.
O usar un repositorio tipo de patrón, con un "thingContext" objeto que es responsable de la persistencia del estado.

Personalmente, yo uso el patrón activeRecord, donde guardar la lógica es al horno en una clase base, pero estoy dejando en favor de un nHibernate de estilo modelo de repositorio.La franquicia de DDD y probando cosas sin un db es muy bueno tener, en un marco de tipo de situación, donde la lógica de negocios ahora está ganando tracción para una nueva interfaz de usuario.

Answer 2

Ahora estoy usando Linq to Sql.Esto resuelve el problema por completo.

Sin embargo, si usted no tiene esa opción (o cualquier otra herramienta ORM), no veo ninguna razón para separar de Lectura/Escritura de métodos.Sólo añade más clases y se complica el acceso a los datos.Siempre he diseñado de la siguiente manera:

1. Componente/Objeto De Negocio:Coche
2. De Acceso a datos, que contiene estática métodos de Lectura y Escritura:CarDB

Ejemplo De Uso:

Car car = new Car();
car.Manufacturer = "Toyota"
car.Model = "Camry"
car.Year = 2006;
car.CarID = CarDB.InsertCar(car)
car.OwnerID = 2;
CarDB.UpdateCar(car);

Esto también tiene sentido para el acceso a datos, donde tanto las Lecturas y la Escritura deben ser realizados como parte de la misma transacción.Si dividir las clases, donde tendría que ir?

Answer 3

Ignorando ORM (porque no estoy ni a favor ni en contra), yo me mantendría en la misma clase.Son las dos facetas de una sola responsabilidad y la separación de ellos sólo tiene que mirar en dos lugares donde realmente no puedo pensar en una buena razón que usted quiere hacer eso.

Answer 4

Algo que se lee y se escribe en un servidor de la tienda que se podría llamar de datos del descriptor de acceso, o ReaderWriter, o IO, o a la Tienda.

Entonces, ¿cómo acerca de uno de los siguientes:

• FooDataAccessor
• FooAccessor
• FooReaderWriter
• FooRW
• FooIO
• FooStore
• FooStorage

Answer 5

Cuando se les da la opción general me subclase del lector para crear el escritor.