Vários diagramas de classe e novas propriedades
Oi!
Eu gostaria de tirar uma dúvida com vocês em relação ao diagrama de classes no Visual Studio. Atualmente participo de um projeto em que na camada que se encontra o diagrama de classes, o mesmo é dividido em diagramas menores. Por exemplo, para um sistema de vendas, haveria um diagrama de classe para os Clientes e lá se encontrariam todos os objetos vinculados com o mesmo, a mesma idéia para Produtos, Pedidos, entendem?
Digamos que é feito uma separação por "assunto" ou "domínio", se é que eu posso colocar dessa forma.
O que eu gostaria de saber se é melhor fazer assim mesmo, separado, ou se o melhor seria tudo em um diagrama só? Faço essa pergunta para saber o que seria melhor para entendimento dos membros da equipe.
E a minha outra pergunta é referente as propriedades de uma classe.
Em algumas situações, faço uso de métodos que retornam uma coleção de objetos com as informações que eu preciso para fazer um bind em um objeto, por exemplo, um GridView. E em algumas situações, para exibir algumas informações no grid, as vezes é necessário mudar a forma de apresentar um texto, concatenar, coisas desse tipo, por exemplo.
Como inicialmente as minhas propriedades são baseadas em informações de uma tabela no banco, eu poderia criar outras propriedades que não tem nada a ver com aquela tabela para fazer este bind usando a coleção de objetos, ou o mais indicado seria mesmo retonar isso em um DataTable?
As vezes faço isso pela última opção, mas acho estranho, hora você retornar objetos mesmo, e hora ficar retornar DataTable ou coisa similar, por isso decidi perguntar.
Hoje a estrutura do projeto é de interface, negócio, persistência e dados. Se fosse para criar as propriedades, poderia criar na de negócio, sem problemas?
Bem, fico no aguardo. Obrigado pela atenção!
Eu gostaria de tirar uma dúvida com vocês em relação ao diagrama de classes no Visual Studio. Atualmente participo de um projeto em que na camada que se encontra o diagrama de classes, o mesmo é dividido em diagramas menores. Por exemplo, para um sistema de vendas, haveria um diagrama de classe para os Clientes e lá se encontrariam todos os objetos vinculados com o mesmo, a mesma idéia para Produtos, Pedidos, entendem?
Digamos que é feito uma separação por "assunto" ou "domínio", se é que eu posso colocar dessa forma.
O que eu gostaria de saber se é melhor fazer assim mesmo, separado, ou se o melhor seria tudo em um diagrama só? Faço essa pergunta para saber o que seria melhor para entendimento dos membros da equipe.
E a minha outra pergunta é referente as propriedades de uma classe.
Em algumas situações, faço uso de métodos que retornam uma coleção de objetos com as informações que eu preciso para fazer um bind em um objeto, por exemplo, um GridView. E em algumas situações, para exibir algumas informações no grid, as vezes é necessário mudar a forma de apresentar um texto, concatenar, coisas desse tipo, por exemplo.
Como inicialmente as minhas propriedades são baseadas em informações de uma tabela no banco, eu poderia criar outras propriedades que não tem nada a ver com aquela tabela para fazer este bind usando a coleção de objetos, ou o mais indicado seria mesmo retonar isso em um DataTable?
As vezes faço isso pela última opção, mas acho estranho, hora você retornar objetos mesmo, e hora ficar retornar DataTable ou coisa similar, por isso decidi perguntar.
Hoje a estrutura do projeto é de interface, negócio, persistência e dados. Se fosse para criar as propriedades, poderia criar na de negócio, sem problemas?
Bem, fico no aguardo. Obrigado pela atenção!
Carlos Nogueira
Curtidas 0
Respostas
Fabio Mans
17/09/2009
Olá vamos por partes.
Dúvida 1
Vamos ver se eu entendi, o que você está pergunta é separar as propriedades e os métodos em diagramas diferente?
Se for, eu gosto de separar, eu chamo uma classe com as propriedade de VO, por exemplo VeiculoVO, a camada de dados eu chamado de VeiculoDAO e a business de BLL, VeiculoBLL, no meu exemplo são três diagramas, outros não gostam de trabalhar desta maneira, se for seguir o padrão POO o correto é como você visualiza o diagrama de classes, propriedades e métodos, ou seja somente um diagrama. Se eu não respondi o que você perguntou, explique novamente.
Dúvida 2
Dependendo do projeto faço igualzinho você, tudo depende, retornar um IList e um objeto eu gosto muito mas da mais trabalho e como as vezes tenho que entregar tudo para ontem eu também utilizo DataTable, você não esta certo nem errado, caso tempo não seja o seu problema retorno um List, sobre a questão de ter que ficar criando propriedades também ocorre comigo, tente modelar o sistema antes, assim evita que várias propriedades sejam criadas, mas sempre isso vai acontecer.
Dúvida 3.
Como eu disse anteriormente eu não gosto de criar as propriedades com a BLL, gostou muito de utilizar a seguinte arquitetura.
http://www.dotnetfunda.com/articles/article18.aspx
Porém ao invés de DataTable eu utilizo IList<> Passing data between layers using Generic list collection http://www.dotnetfunda.com/articles/article472-passing-data-between-layers-using-generic-list-collection.aspx
Espero ter ajudado.
Fabio
================================================================
Oi!
Eu gostaria de tirar uma dúvida com vocês em relação ao diagrama de classes no Visual Studio. Atualmente participo de um projeto em que na camada que se encontra o diagrama de classes, o mesmo é dividido em diagramas menores. Por exemplo, para um sistema de vendas, haveria um diagrama de classe para os Clientes e lá se encontrariam todos os objetos vinculados com o mesmo, a mesma idéia para Produtos, Pedidos, entendem?
Digamos que é feito uma separação por "assunto" ou "domínio", se é que eu posso colocar dessa forma.
O que eu gostaria de saber se é melhor fazer assim mesmo, separado, ou se o melhor seria tudo em um diagrama só? Faço essa pergunta para saber o que seria melhor para entendimento dos membros da equipe.
E a minha outra pergunta é referente as propriedades de uma classe.
Em algumas situações, faço uso de métodos que retornam uma coleção de objetos com as informações que eu preciso para fazer um bind em um objeto, por exemplo, um GridView. E em algumas situações, para exibir algumas informações no grid, as vezes é necessário mudar a forma de apresentar um texto, concatenar, coisas desse tipo, por exemplo.
Como inicialmente as minhas propriedades são baseadas em informações de uma tabela no banco, eu poderia criar outras propriedades que não tem nada a ver com aquela tabela para fazer este bind usando a coleção de objetos, ou o mais indicado seria mesmo retonar isso em um DataTable?
As vezes faço isso pela última opção, mas acho estranho, hora você retornar objetos mesmo, e hora ficar retornar DataTable ou coisa similar, por isso decidi perguntar.
Hoje a estrutura do projeto é de interface, negócio, persistência e dados. Se fosse para criar as propriedades, poderia criar na de negócio, sem problemas?
Bem, fico no aguardo. Obrigado pela atenção!
Dúvida 1
Vamos ver se eu entendi, o que você está pergunta é separar as propriedades e os métodos em diagramas diferente?
Se for, eu gosto de separar, eu chamo uma classe com as propriedade de VO, por exemplo VeiculoVO, a camada de dados eu chamado de VeiculoDAO e a business de BLL, VeiculoBLL, no meu exemplo são três diagramas, outros não gostam de trabalhar desta maneira, se for seguir o padrão POO o correto é como você visualiza o diagrama de classes, propriedades e métodos, ou seja somente um diagrama. Se eu não respondi o que você perguntou, explique novamente.
Dúvida 2
Dependendo do projeto faço igualzinho você, tudo depende, retornar um IList e um objeto eu gosto muito mas da mais trabalho e como as vezes tenho que entregar tudo para ontem eu também utilizo DataTable, você não esta certo nem errado, caso tempo não seja o seu problema retorno um List, sobre a questão de ter que ficar criando propriedades também ocorre comigo, tente modelar o sistema antes, assim evita que várias propriedades sejam criadas, mas sempre isso vai acontecer.
Dúvida 3.
Como eu disse anteriormente eu não gosto de criar as propriedades com a BLL, gostou muito de utilizar a seguinte arquitetura.
http://www.dotnetfunda.com/articles/article18.aspx
Porém ao invés de DataTable eu utilizo IList<> Passing data between layers using Generic list collection http://www.dotnetfunda.com/articles/article472-passing-data-between-layers-using-generic-list-collection.aspx
Espero ter ajudado.
Fabio
================================================================
Oi!
Eu gostaria de tirar uma dúvida com vocês em relação ao diagrama de classes no Visual Studio. Atualmente participo de um projeto em que na camada que se encontra o diagrama de classes, o mesmo é dividido em diagramas menores. Por exemplo, para um sistema de vendas, haveria um diagrama de classe para os Clientes e lá se encontrariam todos os objetos vinculados com o mesmo, a mesma idéia para Produtos, Pedidos, entendem?
Digamos que é feito uma separação por "assunto" ou "domínio", se é que eu posso colocar dessa forma.
O que eu gostaria de saber se é melhor fazer assim mesmo, separado, ou se o melhor seria tudo em um diagrama só? Faço essa pergunta para saber o que seria melhor para entendimento dos membros da equipe.
E a minha outra pergunta é referente as propriedades de uma classe.
Em algumas situações, faço uso de métodos que retornam uma coleção de objetos com as informações que eu preciso para fazer um bind em um objeto, por exemplo, um GridView. E em algumas situações, para exibir algumas informações no grid, as vezes é necessário mudar a forma de apresentar um texto, concatenar, coisas desse tipo, por exemplo.
Como inicialmente as minhas propriedades são baseadas em informações de uma tabela no banco, eu poderia criar outras propriedades que não tem nada a ver com aquela tabela para fazer este bind usando a coleção de objetos, ou o mais indicado seria mesmo retonar isso em um DataTable?
As vezes faço isso pela última opção, mas acho estranho, hora você retornar objetos mesmo, e hora ficar retornar DataTable ou coisa similar, por isso decidi perguntar.
Hoje a estrutura do projeto é de interface, negócio, persistência e dados. Se fosse para criar as propriedades, poderia criar na de negócio, sem problemas?
Bem, fico no aguardo. Obrigado pela atenção!
GOSTEI 0
Carlos Nogueira
17/09/2009
Oi
Reposta da Dúvida 1
Em relação ao que você escreveu na dúvida 1, aqui no projeto nós temos a camada de interface, uma camada de negócios, uma camada para persistência e a camada de dados. Foi legal o artigo que você me passou, ainda não tinha visto exemplo de projeto com uma camada chamada BAL, só mesmo com a DAL.
E também trabalhamos parecido, transportamos dados de uma camada para outra por meio de lista de objetos (ou nas situações de DataTable ou IList que você comentou). O diagrama de classes deste projeto que estou trabalhando se encontra somente na camada de negócio.
Desculpe aproveitar o post, mas qual seria a diferença disso para eu estar trabalhando em um projeto com POO? Eu pensava que estava trabalhando assim.
Então para cada camada eu deveria ter um diagrama de classes? No projeto aqui, a camada de negócio tem vários diagramas de classes, separados por assuntos que lhe falei, tipo, clientes, pedidos, produtos, contas, e assim por diante, para lhe passar um exemplo... Tipo, o que deu a entender aqui é que quando fizeram, desejaram fazer parecido como se fosse diagrama do banco de dados.
Resposta da Dúvida 2
Em relação ao que você escreveu na dúvida 2, do List eu entendi. Das propriedades, é justamente minha dúvida. Se para um gridview por exemplo, você precisa demonstrar em uma coluna a concatenação de 3 propriedades, no datafield do column (ou as vezes do objeto de terceiros) não é possível concatenar essas 3 propriedades, então na hora de retornar para dar um bind que as vezes faço um DataTable, mas queria saber se vocês ou o mercado por ai fora como boa prática faz diferente disso, entendeu? É que venho estudando (ou tentado) orientação a objeto para tentar chegar o mais próximo disso (ou tentar fazer algo legal pelo menos, rsrs).
Bem, fico no aguardo. Valeu!
Reposta da Dúvida 1
Em relação ao que você escreveu na dúvida 1, aqui no projeto nós temos a camada de interface, uma camada de negócios, uma camada para persistência e a camada de dados. Foi legal o artigo que você me passou, ainda não tinha visto exemplo de projeto com uma camada chamada BAL, só mesmo com a DAL.
E também trabalhamos parecido, transportamos dados de uma camada para outra por meio de lista de objetos (ou nas situações de DataTable ou IList que você comentou). O diagrama de classes deste projeto que estou trabalhando se encontra somente na camada de negócio.
Desculpe aproveitar o post, mas qual seria a diferença disso para eu estar trabalhando em um projeto com POO? Eu pensava que estava trabalhando assim.
Então para cada camada eu deveria ter um diagrama de classes? No projeto aqui, a camada de negócio tem vários diagramas de classes, separados por assuntos que lhe falei, tipo, clientes, pedidos, produtos, contas, e assim por diante, para lhe passar um exemplo... Tipo, o que deu a entender aqui é que quando fizeram, desejaram fazer parecido como se fosse diagrama do banco de dados.
Resposta da Dúvida 2
Em relação ao que você escreveu na dúvida 2, do List eu entendi. Das propriedades, é justamente minha dúvida. Se para um gridview por exemplo, você precisa demonstrar em uma coluna a concatenação de 3 propriedades, no datafield do column (ou as vezes do objeto de terceiros) não é possível concatenar essas 3 propriedades, então na hora de retornar para dar um bind que as vezes faço um DataTable, mas queria saber se vocês ou o mercado por ai fora como boa prática faz diferente disso, entendeu? É que venho estudando (ou tentado) orientação a objeto para tentar chegar o mais próximo disso (ou tentar fazer algo legal pelo menos, rsrs).
Bem, fico no aguardo. Valeu!
GOSTEI 0
Fabio Mans
17/09/2009
Desculpe aproveitar o post, mas
qual seria a diferença disso para eu estar trabalhando em um projeto
com POO? Eu pensava que estava trabalhando assim.
============================================
Eu digo POO porque quando aprendemos o diagrama de classes ele contém atributos e propriedades no mesmo diagrama, presumindo a nossa classe também deveria ter os atributos e métodos na mesma classe, mas como eu disse eu gosto de dividir
============================================
---------------------------------------------------------------------------------
Em relação ao que você escreveu na dúvida 2, do List eu entendi. Das propriedades, é justamente minha dúvida. Se para um gridview por exemplo, você precisa demonstrar em uma coluna a concatenação de 3 propriedades, no datafield do column (ou as vezes do objeto de terceiros) não é possível concatenar essas 3 propriedades, então na hora de retornar para dar um bind que as vezes faço um DataTable, mas queria saber se vocês ou o mercado por ai fora como boa prática faz diferente disso, entendeu? É que venho estudando (ou tentado) orientação a objeto para tentar chegar o mais próximo disso (ou tentar fazer algo legal pelo menos, rsrs).
==============================================
Você não está fazendo nada de errado, nos projetos que trabalhei a maioria utilizava DataTable, um bom lugar para você ficar sabendo as novidades de arquitetura é o fórum msdn.
Veja o link
http://social.msdn.microsoft.com/Forums/pt-BR/arquiteturapt/threads
==============================================
Fabio
Oi
Reposta da Dúvida 1
Em relação ao que você escreveu na dúvida 1, aqui no projeto nós temos a camada de interface, uma camada de negócios, uma camada para persistência e a camada de dados. Foi legal o artigo que você me passou, ainda não tinha visto exemplo de projeto com uma camada chamada BAL, só mesmo com a DAL.
E também trabalhamos parecido, transportamos dados de uma camada para outra por meio de lista de objetos (ou nas situações de DataTable ou IList que você comentou). O diagrama de classes deste projeto que estou trabalhando se encontra somente na camada de negócio.
Desculpe aproveitar o post, mas qual seria a diferença disso para eu estar trabalhando em um projeto com POO? Eu pensava que estava trabalhando assim.
Então para cada camada eu deveria ter um diagrama de classes? No projeto aqui, a camada de negócio tem vários diagramas de classes, separados por assuntos que lhe falei, tipo, clientes, pedidos, produtos, contas, e assim por diante, para lhe passar um exemplo... Tipo, o que deu a entender aqui é que quando fizeram, desejaram fazer parecido como se fosse diagrama do banco de dados.
Resposta da Dúvida 2
Em relação ao que você escreveu na dúvida 2, do List eu entendi. Das propriedades, é justamente minha dúvida. Se para um gridview por exemplo, você precisa demonstrar em uma coluna a concatenação de 3 propriedades, no datafield do column (ou as vezes do objeto de terceiros) não é possível concatenar essas 3 propriedades, então na hora de retornar para dar um bind que as vezes faço um DataTable, mas queria saber se vocês ou o mercado por ai fora como boa prática faz diferente disso, entendeu? É que venho estudando (ou tentado) orientação a objeto para tentar chegar o mais próximo disso (ou tentar fazer algo legal pelo menos, rsrs).
Bem, fico no aguardo. Valeu!
============================================
Eu digo POO porque quando aprendemos o diagrama de classes ele contém atributos e propriedades no mesmo diagrama, presumindo a nossa classe também deveria ter os atributos e métodos na mesma classe, mas como eu disse eu gosto de dividir
============================================
---------------------------------------------------------------------------------
Em relação ao que você escreveu na dúvida 2, do List eu entendi. Das propriedades, é justamente minha dúvida. Se para um gridview por exemplo, você precisa demonstrar em uma coluna a concatenação de 3 propriedades, no datafield do column (ou as vezes do objeto de terceiros) não é possível concatenar essas 3 propriedades, então na hora de retornar para dar um bind que as vezes faço um DataTable, mas queria saber se vocês ou o mercado por ai fora como boa prática faz diferente disso, entendeu? É que venho estudando (ou tentado) orientação a objeto para tentar chegar o mais próximo disso (ou tentar fazer algo legal pelo menos, rsrs).
==============================================
Você não está fazendo nada de errado, nos projetos que trabalhei a maioria utilizava DataTable, um bom lugar para você ficar sabendo as novidades de arquitetura é o fórum msdn.
Veja o link
http://social.msdn.microsoft.com/Forums/pt-BR/arquiteturapt/threads
==============================================
Fabio
Oi
Reposta da Dúvida 1
Em relação ao que você escreveu na dúvida 1, aqui no projeto nós temos a camada de interface, uma camada de negócios, uma camada para persistência e a camada de dados. Foi legal o artigo que você me passou, ainda não tinha visto exemplo de projeto com uma camada chamada BAL, só mesmo com a DAL.
E também trabalhamos parecido, transportamos dados de uma camada para outra por meio de lista de objetos (ou nas situações de DataTable ou IList que você comentou). O diagrama de classes deste projeto que estou trabalhando se encontra somente na camada de negócio.
Desculpe aproveitar o post, mas qual seria a diferença disso para eu estar trabalhando em um projeto com POO? Eu pensava que estava trabalhando assim.
Então para cada camada eu deveria ter um diagrama de classes? No projeto aqui, a camada de negócio tem vários diagramas de classes, separados por assuntos que lhe falei, tipo, clientes, pedidos, produtos, contas, e assim por diante, para lhe passar um exemplo... Tipo, o que deu a entender aqui é que quando fizeram, desejaram fazer parecido como se fosse diagrama do banco de dados.
Resposta da Dúvida 2
Em relação ao que você escreveu na dúvida 2, do List eu entendi. Das propriedades, é justamente minha dúvida. Se para um gridview por exemplo, você precisa demonstrar em uma coluna a concatenação de 3 propriedades, no datafield do column (ou as vezes do objeto de terceiros) não é possível concatenar essas 3 propriedades, então na hora de retornar para dar um bind que as vezes faço um DataTable, mas queria saber se vocês ou o mercado por ai fora como boa prática faz diferente disso, entendeu? É que venho estudando (ou tentado) orientação a objeto para tentar chegar o mais próximo disso (ou tentar fazer algo legal pelo menos, rsrs).
Bem, fico no aguardo. Valeu!
GOSTEI 0
Carlos Nogueira
17/09/2009
Beleza, então neste caso pode finalizar o suporte.
Muito obrigado pela sua atenção!
Atenciosamente,
Carlos
Muito obrigado pela sua atenção!
Atenciosamente,
Carlos
GOSTEI 0