Abstraindo Data Access Layer de Negócios Objeto

Question

Não é nada novo para dissociar o código de acesso de dados de seus objetos de negócios, mas estou sempre a olhar-out para a "melhor maneira" para conseguir algo.

Eu tenho as seguintes classes:

Orange -. Este é o meu objeto de negócios

OrangeList - Esta é uma lista de laranjas.

O usuário iria buscar laranja objetos do armazenamento de dados chamando OrangeList.Fetch (someCriteria). Portanto OrangeList tem que ter uma referência para a camada de acesso a dados - por isso tem a propriedade:. IDataProvider MyDataProvider

Isto irá funcionar para mim, mas o problema é que não podemos buscar uma única laranja por si só -. Nós sempre temos que ir via OrangeList

Ou isso, ou ambos laranja e OrangeList teria que descer de algum objeto comum que iria realizar o DataProvider.

Este é um problema, ou é a minha abordagem maneira fora da marca em primeiro lugar?

Qualquer dicas / ponteiros são apreciadas, obrigado.

EDIT:. À luz da discussão abaixo, eu verifiquei o padrão Repository

No entanto, para o meu projeto, eu acho que é uma boa idéia para separar ainda mais o Repositório do DAL.

SO .... O Repositório é como eu fico Laranjas e salvar laranjas, mas ainda não sei como. I delegar que para o IDataProvider, o que poderia ser um número daqueles listados no diagrama.

Para esclarecer - não laranja não sabe como buscar / atualizar-se, certo? É um objeto de negócios PURE? - e é que o ponto

alt texto http://img22.imageshack.us/img22/2460/repositorya .jpg

Caso você esteja se perguntando, o meu "LegacyDataProvider" é apoiar um sistema antigo, que acessa um banco de dados baseado em arquivo (FoxPro, eek) - mas isso deixa-me acabar com isto e mantê-lo de armas de comprimento do meu novo código.

Em termos de construção assembly .NET, para evitar referências circulares parece que eu vou ter um Repository.DLL [OrangeRepo], um DataProviderInterface.DLL [IDataProvider], e uma BusinessObjects.dll [laranja]. Tudo bom?

que eu tenho a idéia do repositório, então?

Answer 1

Eu sugiro a Pattern Repository

Answer 2

Eu (e fazer) compõem todas essas coisas fora de um objeto mestre API (OrangeCart?), Que também compõe um objeto de interface para a camada de acesso a dados. Seus Laranjas e OrangeLists sabe que eles pertencem ao OrangeCart e falar com ele para as operações DAL.

Answer 3

Ao invés de OrangeList (someCriteria), eu teria Oranges.Criteria1List, Oranges.Criteria2List. Para um solteirão, eu teria Oranges.GetItem (orangeId).

Fazendo do seu jeito, o BusinessObject acaba precisando pensar em termos de design de dados lógicos em vez de termos conceituais.

(implementações do Repositório causar-me o mesmo desconforto - muitas vezes tudo o que eles são usados ??para é colocar uma fina camada de abstração grossas código sobre as mesas eu não gosto do BL para nunca ser obrigado a saber sobre a implementação de banco de dados. detalhes como tipos e tamanhos de dados. Muitas vezes é útil para separar esses tipos de dependências.)