Construção de objetos na camada cliente ou comercial?

Question

Algo que notei ao examinar vários kits iniciais do .NET é que a construção de objetos de negócios geralmente é tratada no nível do cliente.Em seguida, o objeto de negócio é passado para a camada de negócio para manipulação, serialização no banco de dados, etc.Esse código não deveria ser abstraído para a camada de negócios, para que o cliente só precisasse passar os dados necessários?Existe alguma vantagem em ter uma camada de negócios com abstrações CRUD que aceitam apenas objetos como argumentos?

Answer 1

Concordo com você que a interação com a camada de negócios deve ser mantida o mais simples possível, com tipos complexos e outras complexidades escondido, ou então qual é o objetivo.No ponto em que a interface do usuário e os objetos de negócios estão conectados, deve haver complexidade o mais próximo possível de 0.

Posso imaginar cenários onde a construção de tipos relativamente complexos naquele ponto seria legítima.Quanto menor for o site, maior será a probabilidade de que <3 níveis possam realmente ser melhores do que os 3 níveis estritos.Portanto, para ter a mente aberta sobre os kits iniciais que você está vendo:talvez o âmbito seja tão pequeno que a separação estrita de preocupações seria um exagero, e a sua abordagem poderia muito bem ser apropriada para a situação.Ou o que eles estão fazendo é tão complexo que esta é a melhor maneira de lidar com isso.Quanto mais complexa a conexão ou integração, ou se houver um modelo de plug-in ou algo assim, um tipo aparentemente excessivamente complexo pode realmente ser o que garante uma interface flexível e consistente.Às vezes, um pouco de complexidade em um lugar economiza muita complexidade em outro lugar.Mas mais frequentemente este não é o caso.Meu palpite é que o que você vê como ruim realmente é... ruim.

1. Muitos início rápido da Microsoft demonstraçõese modelos tem uma arquitetura muito ruim.O próprio modelo de formas da Web não se presta a uma boa separação de preocupações.Você verá muitos exemplos oficiais que sãocódigo espaguete pesadelos.A interface de negócios, banco de dados e usuário morando juntos é uma harmonia horrível.
2. Se você está falando sobre SDKs de terceiros:Muitos deles exigem tipos complexos passados ​​para os objetos de negócios porque foram portados do C ++, mas nunca são realmente revisados ​​para serem orientados a objetos.Algumas vezes eu tive que fazer alguns tipos insanos para passar para alguns objetos de software de imagem, onde logicamente eram necessários apenas dois parâmetros de valor simples.

Answer 2

Eu normalmente faria esse tipo de trabalho em um Serviço ou camada de acesso a dados. Ou seja, para o projeto menor, tenho minha camada de acesso a dados, retorna meus objetos de domínio. Para projetos maiores, eu usaria uma camada de serviço para lidar com a construção complexa de objeto e a invocação da lógica de negócios.