camada de negócios com vários objetos com todas as propriedades preenchidas do banco de dados ou um objeto com apenas um subconjunto preenchido

Question

Estou construindo um sistema de tamanho médio e estou enfrentando um problema que provavelmente alguns de vocês já enfrentaram.Na minha camada de negócios eu retorno objetos de negócios com um subconjunto de propriedades que são importantes para aquele método de negócios, estou preocupado porque posso acabar com muitos objetos com nomes sem sentido ou apenas um onde apenas um subconjunto de propriedades é preenchido em um determinado método.Deixe-me dar um exemplo.

Caso 1

Por exemplo, um usuário pertence a uma cidade, que por sua vez pertence a um estado e a um país, User, City, State e Country são tabelas no meu banco de dados com muitos campos, mas quero uma lista de usuários com uma lista de Pedidos, então crio um business object chamado por exemplo UserWithOthers apenas com as propriedades importantes (UserId, UserName, CityName, StateName, CountryName, List<Order>) e meu DAL recupera apenas esses campos do banco de dados.

Caso 2

Quero retornar agora um usuário com a quantidade de pedidos, finalizo com os seguintes campos no meu business object (UserId, UserName, CityName, StateName, CountryName, OrdersCount) e a classe poderia ser chamada, por exemplo UserWithOrderCount

Pensei em algumas opções:

1. Faça essas duas classes de negócios e preencha-as separadamente em cada método DAL (estes objetos são simples, mas considere que o método pode ter uma consulta de seleção complexa que precisa ser encapsulada para reutilização, então o padrão de repositório não se encaixa bem aqui, pelo menos eu acho que ).
2. Crie apenas um objeto User com todas as propriedades (UserId, UserName, CityName, StateName, CountryName, OrdersCount, List<Order>) e preencher apenas um subconjunto em cada método DAL, mas isso implica em Acoplamento Semântico quando você usa um método, porque você deve saber qual subconjunto de campos é preenchido no banco de dados, e o acoplamento semântico é o pior de todos os acoplamentos.
3. A opção 1 não funciona bem se eu precisar posteriormente de outra visualização, ambas, List<Order> e OrdersCount propriedades.
4. Considere agora que se você usar as boas práticas do ASP.NET MVC diz que você precisa de um ViewModel para passar para a view, pensei em retornar ViewModels da minha camada de negócios, mas não acho que seja uma boa ideia, parece que estou violando alguma coisa, e também não é possível porque minha camada de negócio está em outro assembly e não na aplicação web.
5. Não quero escrever a mesma consulta Linq repetidamente, mas se usar NHibernate ou EFCodeFirst for "como" a opção um, precisarei criar vários objetos de pequenas empresas.

Como você lida com essa situação?Acho que esta é uma decisão de design de alto nível.

Answer 1

Em primeiro lugar, concordo definitivamente com você sobre algumas coisas que não devemos fazer:

1. Não preencha parcialmente os objetos de negócios, pois você atribui a responsabilidade de saber quais propriedades são preenchidas aos clientes da camada de negócios, o que é uma prática muito ruim.

2. Não retorne ViewModels da sua camada de negócios;sua camada de negócios deve representar os conceitos de negócios do domínio do seu aplicativo, e um ViewModel é um objeto de dados que contém os dados necessários para exibir uma visualização específica de uma parte desse domínio - as duas são coisas muito diferentes e a camada de negócios deve estar completamente inconsciente de que seus objetos de negócios são usados ​​em qualquer tipo de GUI.

Eu seguiria sua primeira sugestão: crie um objeto de negócios separado para representar cada conceito de negócio.Eu então usaria um ORM (como EF ou NHibernate) para preencher esses objetos para mim, com repositórios dedicados para cada grupo de objetos.Eu usaria então uma camada de aplicativo que chama os repositórios para retornar quaisquer objetos necessários.para esse fim, seu Repositório pode incluir métodos que retornam Usuários e Pedidos unidos para momentos em que você sabe que precisa usar esses dois tipos juntos.Isso permite que você retorne um Usuário com todos os seus Pedidos em uma consulta, mantendo entidades separadas e significativas para representar Usuários e Pedidos.