Melhores práticas de camada de dados

Question

Estou no meio de uma "discussão" com um colega sobre a melhor forma de implementar a camada de dados em um novo aplicativo.

Um ponto de vista é que a camada de dados deve estar ciente dos objetos de negócios (nossas próprias classes que representam uma entidade) e ser capaz de trabalhar com esse objeto nativamente.

O ponto de vista oposto é que a camada de dados deve ser independente de objetos e lidar puramente com tipos de dados simples (strings, bools, datas, etc.)

Posso ver que ambas as abordagens podem ser válidas, mas o meu ponto de vista é que prefiro a primeira.Dessa forma, se o meio de armazenamento de dados mudar, a camada de negócios não precisará (necessariamente) mudar para acomodar a nova camada de dados.Portanto, seria algo trivial mudar de um armazenamento de dados SQL para um armazenamento de sistema de arquivos XML serializado.

O ponto de vista do meu colega é que a camada de dados não deveria ter que saber sobre as definições dos objetos e que, desde que os dados sejam transmitidos de forma adequada, isso é suficiente.

Agora, eu sei que esta é uma daquelas questões que tem o potencial de iniciar uma guerra religiosa, mas eu apreciaria qualquer feedback da comunidade sobre como você aborda essas coisas.

TIA

Answer 1

Realmente depende da sua visão do mundo - eu costumava estar no campo desacoplado.O DAL estava lá apenas para fornecer dados ao BAL – fim da história.

Com tecnologias emergentes como Linq to SQL e Entity Framework se tornando um pouco mais populares, a linha entre DAL e BAL ficou um pouco confusa.Especialmente no L2S, seu DAL está fortemente acoplado aos objetos de negócios, pois o modelo de objeto possui um mapeamento 1-1 para o campo do seu banco de dados.

Como tudo no desenvolvimento de software, não existe resposta certa ou errada.Você precisa entender seus requisitos e exigências futuras e trabalhar a partir daí.Eu não usaria mais uma Ferrari no rali Dakhar como usaria um Range Rover em um track day.

Answer 2

Você pode ter os dois.Deixe que a camada de dados não conheça seus objetos de negócios e torne-a capaz de trabalhar com mais de um tipo de fonte de dados.Se você fornecer uma interface comum (ou uma classe abstrata) para interagir com os dados, poderá ter implementações diferentes para cada tipo de fonte de dados.O padrão de fábrica vai bem aqui.

Answer 3

Um excelente livro que tenho, que aborda esse assunto, é Padrões de acesso a dados, de Clifton Nock.Ele contém muitas boas explicações e boas ideias sobre como dissociar sua camada de negócios da camada de persistência.Você realmente deveria tentar.É um dos meus livros favoritos.

Answer 4

Jeffrey Palermo escreveu um bom post sobre isso.Ele chamou isso Arquitetura Cebola.

Answer 5

Um truque que achei útil é fazer com que minha camada de dados seja "independente de coleção".Ou seja, sempre que desejo retornar uma lista de objetos da minha camada de dados, faço com que o chamador passe na lista.Então, em vez disso:

public IList<Foo> GetFoosById(int id) { ... }

Eu faço isso:

public void GetFoosById(IList<Foo> foos, int id) { ... }

Isso me permite passar uma lista simples e antiga, se isso for tudo que preciso, ou uma implementação mais inteligente de IList<T> (como ObservableCollection<T>) se planejo vincular a ela a partir da interface do usuário.Essa técnica também me permite retornar coisas do método, como ValidationResult, contendo uma mensagem de erro, caso ocorra.

Isso ainda significa que minha camada de dados conhece minhas definições de objeto, mas me dá um grau extra de flexibilidade.

Answer 6

Confira Linq to SQL, se eu estivesse criando um novo aplicativo agora, consideraria confiar em uma camada de dados inteiramente baseada em Linq.

Fora isso, acho uma boa prática dissociar dados e lógica tanto quanto possível, mas isso nem sempre é prático.Uma separação pura entre lógica e acesso a dados dificulta junções e otimizações, o que torna o Linq tão poderoso.

Answer 7

Em aplicações onde usamos o NHibernate, a resposta se torna "em algum lugar no meio", pois, enquanto as definições de mapeamento XML (elas especificam qual tabela pertence a qual objeto e quais colunas pertencem a qual campo, etc.) estão claramente na camada de objeto de negócio .

Eles são passados ​​para um gerenciador de sessão de dados genérico que não tem conhecimento de nenhum dos objetos de negócios;o único requisito é que os objetos de negócios passados ​​a ele para CRUD tenham um arquivo de mapeamento.

Answer 8

Post antigo, mas procurando informações semelhantes me deparei esse o que explica muito bem.