Divisão em Camadas - "Minha arquitetura"

Question

Pessoal,

 

Fiz uma arquitetura onde eu criei quatro projetos:

• DAL: Camada de Persistência com a acesso ao banco;
• BLL: Camada de Negócios, onde irei validar toda a regra de negócio;
• Model: É onde possuo as entidades;
• Apresentação: Windows Forms, onde tenho a interface do usuário, cadastros, etc..

Em cada camada, criei uma classe abstract, como:

DALBase, BLLBase, CadastroBase(Camada de Apresentação) e ModelBase.

 

Na classe BLLBase, eu tenho uma propriedade ModelBase. Na classe UsuarioBLL, eu instancio esta propriedade chamando um UsuarioModel que herda do ModelBase.

 

Na classe CadastroBase, eu tenho uma propriedade do tipo BLLBase.

Então, ao cadastrar algo, eu uso:

BLL.Model.SetValue<Int32>(txtMatricula.Text.Trim(), "Email", Convert.ToInt32);

 

Onde eu passo o valor do controle no primeiro parametro, o nome da propriedade no segundo parametro e o método a ser utilizado para converter do valor do controle para a propriedade que eu especifiquei. Essa conversão e esse preenchimento dos dados, eu faço utilizando Reflection.

 

Enfim, eu preenchendo o Model da classe BLL, eu faço a validação da regra de negócio.

 

Acho que consegui resumi um pouco a arquitetura que estou utilizando em um dos meus projetos.

Alguém tem alguma sugestão? crítica?

 

Valeu

 

 

 

Answer 1

 

Olá amigo, sou iniciante em C# e em POO. Onde posso aprender esse tipo de arquitetura "N Camadas"? se puder me ajudar eu agradeço, e muito!

Answer 2

Eu estou desenvolvendo um sistema do zero e sou o responsável por ele. É o primeiro sistema .Net da empresa, outros ainda estão em VB6, e eu quis começar certo.

Portanto também estou fazendo o possível para utilizar padrões, arquitetura e conhecimentos que eu tive em outros projetos.

Essa arquitetura, do tópico que abre o post, é conhecida como MVC, saiu um artigo prático na edição 46, se não me engano, da .Net Magazine da Dev Media. Ela também é referenciada nos PDF's do Pratices & Patterns.

 

Essa é a primeira vez que eu fico responsável por definir a arquitetura, padrões e etc. de um projeto zerado; portanto encontra dificuldades e etc. Se quiserem trocar idéias meu msn é egomesbrandao @ hotmail.com.

Answer 3

 

Fala Brandão, estou na mesma situação que você, definindo a arquitetura do primeiro sistema em .NET da empresa, e lembrando que não tenho muita experiência em orientação a objetos.

Minha dúvida é quando a apresentação de dados de várias tabelas, em uma tela de consulta por exemplo.

Da maneira que estou fazendo (o projeto ainda não entrou na fase de codificação somente tenho protótipos/testes em situações não reais) , quando estamos fazendo cadastros eu crio uma classe que representa a tabela do banco de dados e esta é minha classe de presistência. Para "circular" pelo programa eu "circulo" estas classes ou coleções delas, não uso datatables ou datasets, somente coleções. Agora quando tenho uma tela em que tenho que ter várias informações de várias tabelas juntas, é errado eu criar uma classe de persistência para a consulta da tela em específico? Em tese eu estaria criando uma classe meio que especificamente para uma tela, é errado isso?

 

Quem puder opinar eu agradeço!

 

Obrigado pela atenção!

Jo

Answer 4

MiTzzz,

na minha opinião, a camada de apresentação deve saber o mínimo de detalhes das camadas de negócios. No seu caso, não acho interessante determinar, na UI, como a propriedade deve ser convertida.

Isso porque, se você resolver mudar de UI, o comportamento será o mesmo para as propriedades.

 

Do resto, para um sistema simples e sem saber ao todo o objetivo de seu projeto, está certo.

 

Abraços.

 

--

André Nobre

http://www.andrenobre.com.br/blog

Answer 5

Jo,

 

Esses artigos podem te ajudar a conhecer o que é a arquitetura MVC:

 

http://fragmental.com.br/wiki/index.php/Evitando_VOs_e_BOs

http://fragmental.com.br/wiki/index.php/MVC_e_Camadas

http://fragmental.com.br/wiki/index.php/Fantoches

Os arquivos do Patterns & Pratices também tem informações.

 

Conforme você irá ler nos artigos do Phillip Calçado o mais comum é encontrar objetos que são só coleções de dados, mas nenhum método. Que é como esta meu sistema hoje, por motivos de entrega vou deixar ele assim, mas depois vou evoluir a arquitetura para MVC mesmo!

Hoje as minhas classes Modelo (classes de dados) são preenchidas na camada DAL e eu faço Bind na camada de apresentação com elas mesma, não passa para outras.

Quando eu tiver um protótipo funcional vou escrever no meu blog de uma maneira mais mastigada como montar essa arquitetura.

Answer 6

Algumas pessoas me enviaram e-mail pedindo maiores detalhes do Projeto. Vou postar aqui como que ele está atualmente.

 

Eu tenho 4 Projetos, são eles: Interface, BLL, DAL e Model.

Na Interface, tenho tudo referente a apresentação. Ela possue a entrada e saída de dados.
A Model é como se fosse uma camada de transporte, pois é através dela que eu me comunico entre as camadas. Ela é como se fosse uma classe Beans do Java, onde possuo somente os atributos e suas respectivas propriedades.

Quem faz o trabalho de leitura e preenchimento dos dados da Apresentação para a Model é a BLL, onde tenho também todas regras de negócio. A partir da BLL é que me comunico com a DAL, que é responsável pelo conhecimento do banco de dados. Então,  no final das contas tenho um relacionamento 1:1:1, porém ficou tudo muito bem separado, de forma que se um dia mudarmos de banco de dados, teremos apenas que mexer com a a classes DAL. Se mudarmos de Windows para Web, iremos ter um esforço menor, criando um Projeto Web e talvez mudando alguma coisa na BLL. Eu achei esta arquitetura muito interessante, claro que sempre pode haver melhorias, mas é dessa forma que vamos evoluindo constantemente. Portanto, críticas e sugestões serão sempre bem vindas.

Answer 7

fala Mitzz.. blz??

 

ainda fiquei com uma duvida referente a sua arquitetura...

 

como vc faz para a sua interface (aspx) se comunicar com a BLL???

 

imagine que vc tem uma tela Pessoa.aspx com os seguintes campos: Nome, Endereco, Idade e um botao gravar.

 

como ficaria essa arquitetura sua para o caso acima???

 

obrigado pela suas respostas...

 

aguardo.....

 

Answer 8

Caros:

 

1. Cuidado com o Reflection, as vezes ccriar uma mapper através da entidade para pontar o DAL no é muito mal ou feio. Lembre-se que a melhor arquitetura nem sempre está relacionada com a melhor tecnologia. Como diria minha sogra "cada um cada".

 

2. Entre as camadas deve ser enviado, em grande parte das vezes, Entidade. Lembre-se do padrao VO foi criado para esse objetivo: "caminhar entre as camadas".

 

3. O dominio deve saber o estado da persistencia para determinar quando guardar ou alterar um registro.

 

Minha sugestao: http://msdn2.microsoft.com/en-us/library/aa697427(VS.80).aspx

 

 

 

Abs

-Fernando Costa

http://sushinetcode.blogdrive.com

 

 

 

Answer 9

 Acho que a melhor disciplina para esse tipo de negocio é prática. No meu caso o padrão MVC  que uso é 3 camadas simples, simples


             apresantação-->capa de acesso a dados/regras de negocio --> SGBD

Portanto fica bem claro. persistente, facil utilização e disponibilização para equipe em outras camadas diferentes como Web, mobile, e etc....

onde essa capa de acesso a dados e as regras de negocio pode ficar numa assembly do tipo DLL. que não precisa de registro somente crtl+c -- ctrl+v...e pronto...

Tudo bem...padrões podem ser utilizado..mas devem ser bem analisado. porque..por exemplo. pensando na OOP.

 herança é muito bom, mas pode torna um tisuname se não for definida em suas respectivas classes. desde o analise do modelo das fases,  como estados, atividades, caso de uso do sistema...

Answer 10

O link abaixo mostra um desejo macro de como minhas camadas se comunicão:

 

http://www.topliga.com.br/images/camadas.jpg

 

Para mais detalhes me enviem um e-mail:

 

[e-mail]

 

Answer 11

MiTzzz wrote:

Quem faz o trabalho de leitura e preenchimento dos dados da Apresentação para a Model é a BLL, onde tenho também todas regras de negócio. A partir da BLL é que me comunico com a DAL, que é responsável pelo conhecimento do banco de dados. Então,  no final das contas tenho um relacionamento 1:1:1, porém ficou tudo muito bem separado, de forma que se um dia mudarmos de banco de dados, teremos apenas que mexer com a a classes DAL.

MiTzzz,

Ao criar as camdas BLL e Model da forma como você está fazendo, você quebra um princípio básico da OO que é manter dados + comportamento dentro do mesmo objeto.

Ou seja, caso eu tenha o conceito "Cliente" no meu domínio eu não devo criar o grupo: ClienteBO + ClienteVO; e sim a entidade Cliente.

[]s

Answer 12

FernandoCosta_Brasil wrote:

Caros:   1. Cuidado com o Reflection, as vezes ccriar uma mapper através da entidade para pontar o DAL no é muito mal ou feio. Lembre-se que a melhor arquitetura nem sempre está relacionada com a melhor tecnologia. Como diria minha sogra "cada um cada".   2. Entre as camadas deve ser enviado, em grande parte das vezes, Entidade. Lembre-se do padrao VO foi criado para esse objetivo: "caminhar entre as camadas".   3. O dominio deve saber o estado da persistencia para determinar quando guardar ou alterar um registro.   Minha sugestao: http://msdn2.microsoft.com/en-us/library/aa697427(VS.80).aspx       Abs -Fernando Costa http://sushinetcode.blogdrive.com

Não entendi o que você disse no item #2. A menos que você esteja falando sobre o padrão Value Object (Domain-Driven Design) não faz sentido alguma criar objetos para "caminhar entre as camadas".

[]s

Answer 13

Laércio Queiroz wrote:

MiTzzz, Ao criar as camdas BLL e Model da forma como você está fazendo, você quebra um princípio básico da OO que é manter dados + comportamento dentro do mesmo objeto. Ou seja, caso eu tenha o conceito "Cliente" no meu domínio eu não devo criar o grupo: ClienteBO + ClienteVO; e sim a entidade Cliente. []s

 

Não entendi isso. Poderia explicar??

 

Answer 14

Cristiano Martinelli wrote:

Laércio Queiroz wrote: MiTzzz, Ao criar as camdas BLL e Model da forma como você está fazendo, você quebra um princípio básico da OO que é manter dados + comportamento dentro do mesmo objeto. Ou seja, caso eu tenha o conceito "Cliente" no meu domínio eu não devo criar o grupo: ClienteBO + ClienteVO; e sim a entidade Cliente. []s   Não entendi isso. Poderia explicar??

Vamos lá....

Objeto é composto por dados (atributos) + comportamento (métodos). O objeto é responsável por fazer as validações necessárias para garantir suas invariantes, mantendo-se num estado válido. Se eu separo isso, criando um objeto com os dados e outro com o comportamento, estou escrevendo código procedural e não OO!

[]s