Divisão de acesso de dados de classe no leitor e escritor, ou combiná-los?

Question

Este pode ser o "discussy" de lado, mas eu realmente gostaria de ouvir sua opinião sobre isso.

Anteriormente eu muitas vezes tenho escrito classes de acesso a dados que tratou da leitura e da escrita, o que muitas vezes levou a uma nomeação, como FooIoHandler etc.A regra de que as classes que são difíceis de nome, provavelmente, são mal projetadas, sugere que esta não é uma boa solução.

Então, eu recentemente comecei a divisão de acesso a dados em FooWriter e FooReader, o que leva a mais agradável nomes e dá alguma flexibilidade adicional, mas ao mesmo tempo eu gosto de como mantê-lo juntos, se as classes não são grandes.

É um leitor/gravador de separação de um design melhor, ou devo combinar?Se eu combiná-los, o que diabos eu deveria nome da classe?

Graças /Erik

Answer 1

ORM pode ser a sua melhor solução.
Ou usar um tipo de repositório padrão, com uma "thingContext" objeto que é responsável pela persistência de estado.

Pessoalmente, eu uso o activeRecord padrão, onde guardar a lógica é cozido em uma classe base, mas eu estou deixando-a em favor de um nHibernate estilo padrão do repositório.A provisão para DDD e o teste de coisas sem um db é muito bom para se ter em um quadro tipo de situação, onde a minha lógica de negócios agora está ganhando tração para uma nova INTERFACE de usuário.

Answer 2

Eu agora estou usando o Linq to Sql.Isto resolve totalmente o problema.

No entanto, se você não tem essa opção (ou algum similar ferramenta ORM), não vejo qualquer razão para se separar de Leitura/Gravação métodos.Ele apenas adiciona mais classes e dificulta o acesso a dados.Eu sempre desenhado da seguinte forma:

1. Componente/Objeto De Negócio:Carro
2. O Acesso a dados, contendo informações estáticas métodos de Leitura e Escrita:CarDB

Exemplo 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);

Isso também faz sentido para acesso a dados, onde ambas as Leituras e Escrita precisam ser realizadas como parte da mesma transação.Se você dividir as classes, onde gostaria de ir?

Answer 3

Ignorando ORM (não porque eu sou a favor ou contra ele) gostaria de mantê-los na mesma classe.Eles são as duas facetas de um único e responsabilidade de separá-las só faz você olhar em dois lugares, onde eu realmente não posso pensar em um bom motivo você iria querer fazer isso.

Answer 4

Algo que lê e grava um backend de armazenamento poderia ser chamado de um acessor de dados, ou ReaderWriter, ou IO, ou Loja.

Então, como sobre um dos seguintes:

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

Answer 5

Quando dada a opção eu geralmente subclasse o leitor para criar o escritor.