none
Onde vai o código? (aplicação em 3 camadas)

    Pergunta

  • Olá a todos.

     

    Atualmente venho estudando o desenvolvimetno de programas em 3 camadas...

     

    Deixem-me explicar minha aituação:

     

    Tenho uma classe "generica" para o acesso a dados, ela recebe alguns parametros e executa os comando com o banco de dados. Ela (a classe) faz parte da camada de dados da aplicação.

     

    Então em cada aplicação diferente, na camada de negócios tem suas classes, como exemplos cliente, funcionário...emfim e cada um deles com seus metodos e atributos.

     

    E a camada de apresentação para exibir o conteudo e tal.

     

    Eu quero criar uma classe para que estaciando um objeto dela, eu possa navegar em registros de um determinado conjunto, por exemplo datatable ou dataset. Essa classe teria os métodos de ir ao primeiro registro, anterior, próximo e ultimo. assim como o bindingNavigator...

     

    Mas estou com um duvida.

     

    Deixem eu tentar me explicar: Aonde eu devo deixar instanciado um objeto como um datatable ou dataset para que eu possa passa-lo como parametro para a minha classe, e poder navegar em seus registros? Seria na camada de negócios junto com os objetos da aplicação?

     

    Minha intenção é que quando eu quiser colocar na aplicação um botão com função para navegar em registros eu somente coloca-se uma rotina como por exemplo: csNavegador.proximo()... e assim por diante.

     

    Estou meio confuso ainda nessa parte de navegação em registros. Eu quero manter uma boa prática nesse conceito de aplicação em 3 camadas. É o que tá faltando pra mim eu acho.

     

    Err... fai ser util o que eu to tentando fazer? E Seria errado colocar o código para navegar nos registros diretamente na camada de apresentação? Mesmo se o dataset/datatable não estiver na mesma camada?

     

    Bom, desculpem pelo longo post.

     

    Espero a ajuda de vocês e obrigado pela atenção.

     

    Att,

     

     

    Felipe.

    quarta-feira, 16 de julho de 2008 17:37

Respostas

  • Jogue os datasets no lixo.
    Datasets são seus dados convertidos em XML, ou seja, é um overhead absurdamente alto.
    Visto que o .Net é capaz de fazer binding com Linq e com objetos, convém usar estes recursos.

    Por exemplo, você pode falar que o DataSource de um grid é um Object (uma classe sua). O controle de datasource o permitirá então a definir seus métodos Select, Insert e Update (assim como parâmetros, etc.)

    Desta forma, o grid irá fazer binding com uma classe POCO (uma classe que só tem propriedades, nenhum método) e cada ação CRUD (Select, Insert, Update & Delete) será um método qualquer teu (que até podem ser métodos da sua classe, porém não é aconselhável).

    Desta forma, você deixa de usar Dataset e passa a fazer binding na UI diretamente de seus objetos na camada correta.
    sábado, 19 de julho de 2008 19:10

Todas as Respostas

  • Se você está em 3 camadas, então não deveria estar usando DataSet, correto?
    Usar DataSet implica em acessar diretamente a fonte de dados da camada de apresentação (assumindo que seu DataSource seja Sql)
    A forma mais correta aí seria um DataSource To Object ou serviços.
    Desta forma, seu DataSet representaria um objeto ou serviço, e não mais a sua fonte de dados.
    E digo fonte de dados porque você, com dataset, sequer passa pelas 2 camadas superiores.

    Quanto à "navegação", como é um ato da UserInterface e não tem absolutamente nada a ver com as camadas superiores, o código fica na UI.

    Você deve pensar da seguinte forma:

    1) Este código faz sentido existir nesta camada se eu, por exemplo, mudar a user interface de web para windows forms? Não? Então este código faz parte da UI.

    2) Este código funciona nesta camada, que não é a UI, somente se a UI existir e somente se a UI existir exatamente desta forma? Sim? Então este código faz parte da UI.

    O segredo é isolar.

    Cada camada tem que ser independente a ponto de uma camada inteira ser substituída e nenhum impacto ocorrer.

    E sim, é absurdamente complicado fazer isso sendo que poderíamos apenas botar um DataSource para Sql e fazer o acesso via dataset diretamente... Mas, quem disse que arquitetura serve para facilitar a vida do dev? =P
    sábado, 19 de julho de 2008 05:14
  • Obrigado JCKödel por responder... mas agora você me deixou um pouco confuso.... acho que estou pensando erroneamente ainda em aplicações em 3 camadas...

    Assim... eu uso dataset mas quem pode realmente modificar os dados é a camada de negócios com a ajuda das funções da camada de dados...

    Minhas classes são tem o seguinte formato por enquanto:

    Vamos a um exemplo de cliente (bem simples!!!)

    No banco de dados tem uma tabela Clientes com os campos CodCliente e NomeCliente...

    Então crio uma classe assim:
    Atributos: dataset - onde terá carregado a tabela cliente com todos os registros
                   codigo - codigo do cliente
                   nome - nome do cliente

    Esses ultimos dois guardando os dados do registro atual...

    Então crio os métodos para manipular esses clientes como inserir novos clientes...deletar...modificar... todos usando as funções da camada de dados (onde tenho uma classe com várias subs para ajudar a acessar o banco de dados)...

    Mas vejo problemas com essa minha "arquitetura"... pois cada classe teria um um dataset....

    Pensei em criar apenas um dataset e adicionar as tables que eu nescessitar... mas não sei se isso ainda seria correto...

    Eu tenho uma classe também que recebe um currencyManager (ByRef) que dispoe métodos como proximo(), anterior(), ultimo()..... assim eu posso chamar esses métodos na camada de aprentação...isso é uma boa idéia??


    Acho que deve repensar e estudar mais essa arquitetura em 3 camadas...to meio perdido ainda!


    Agradeço a atenção novamente...

    Att
    Felipe
    sábado, 19 de julho de 2008 18:56
  • Jogue os datasets no lixo.
    Datasets são seus dados convertidos em XML, ou seja, é um overhead absurdamente alto.
    Visto que o .Net é capaz de fazer binding com Linq e com objetos, convém usar estes recursos.

    Por exemplo, você pode falar que o DataSource de um grid é um Object (uma classe sua). O controle de datasource o permitirá então a definir seus métodos Select, Insert e Update (assim como parâmetros, etc.)

    Desta forma, o grid irá fazer binding com uma classe POCO (uma classe que só tem propriedades, nenhum método) e cada ação CRUD (Select, Insert, Update & Delete) será um método qualquer teu (que até podem ser métodos da sua classe, porém não é aconselhável).

    Desta forma, você deixa de usar Dataset e passa a fazer binding na UI diretamente de seus objetos na camada correta.
    sábado, 19 de julho de 2008 19:10
  • Dá uma lida neste artigo:

    http://www.linhadecodigo.com.br/Artigo.aspx?id=596
    sábado, 19 de julho de 2008 19:17
  • JCKödel


    Muito obrigado mais uma vez. E muito bom  o artigo que você me indicou.  Eu continuei a pesquisar e acabei por encontrar esse artigo aqui:
    http://oakcool1979.spaces.live.com/blog/cns!48D0D78BC2BA6C5!168.entry


    Acredito que seja mais ou menos isso o que você gostaria de me falar não é mesmo? Não precisamos mesmo usar datasets...


    Mas agora  surgiram  outras dúvidas: uma é sobre a navegação dos registros.  no artigo ali que eu lí e  no que você me passou, ambos  vinculam os objetos de dados com  um datagrid  ou datagrid view... ou seja , que mostram vários registros de uma só vez. Que tipo de estrutura eu devo tentar criar para que eu possa navegar em textbox simples? Que mostrem apenas 1 registro por vez?

    Não sei se fui claro. Eu pensei assim: no artigo que eu lí, ele cria no método que busca todos os clientes e esse método retorna um List com os objetos clientes... ai tem uma variavel criada no form de apresentação para guardar essas informações. Então, o que você propoe que se faça? Eu poderia criar que tipo de estruturas para guardar essa "coleção" de objetos para poder "andar" pelo seus registros usando o bidingContext (pois eu vincularia os textbox com essa "estrutura" que guardaria essa coleção!): Eu poderia usar aquela que você me propos? objectDatasource (ele não é apenas para windows forms?)? ou você tem uma outra idéia pra me propor?

    É que antes eu usava um datatable de um dataset para associar uma priedade biding do text box para a vinculação... mas agora não vejo ainda como fazer isso de outra forma...continuarei pesquisando rsrs....

    Tem outras dúvidas, mas acho que já alonguei de mais rsrs...


    Obrigado novamente.

    Att,

    Felipe.
    segunda-feira, 21 de julho de 2008 01:21
  • Veja bem... binding em .Net SEMPRE é uma coleção.

    DataSet é uma coleção de DataTables que é uma coleção de Rows.

    Analogicamente, uma lista ou um arraylist de objetos é uma coleção de suas entidade.

    Trocando em miúdos: não importa pro .Net se é um dataset ou uma lista de objetos. Vai continuar funcionando igualmente paginação, navegação, etc...

    Se você inserir aqueles controles que montam a toolbar de primeiro, anterior, próximo, último e fazer binding com objectsource, ele ainda vai conseguir fazer tudo normal... não tem diferença alguma pra ele.

    O BindingNavigator  tem os métodos First, Next, Last, etc... Não importa se é dataset ou uma coleção de objetos.

    Aparentemente, o .Net faz binding com um ICollection (como o artigo demonstra).

    Não sei se você está em Windows Forms ou ASP, mas dá uma olhada no componente BindingNavigator... Ele faz sozinho a navegação dos registros, não importando se é dataset ou lista de objetos no bindingsource...

    Com certeza todos os componentes que realizam databinding irão funcionar sem nenhuma diferença, não importando que tipo de source você utilize.

    Acabei de fazer um projeto aqui usando o DataRepeater do ASP lendo uma coleção via Linq to Sql e, do resultado desta, gerando uma lista com objetos customizados e funcionou de boa... Não estou lendo direto do linq para o DataRepeater porque tem campos que eu calculo, então é como se fosse uma business entity na minha camada de negócios.

    E se eu quiser usar Windows Forms + BindingNavigator para a mesma coleção, não preciso fazer absolutamente nada nas camadas superiores (ou seja, que não seja a UI)
    segunda-feira, 21 de julho de 2008 01:31
  • Que rápido a resposta XD!

    Mas acredito que compreendi agora. Sobre o bidingNavigator, eu não tive ma boa experiencia com ele... foi no primeiro (e unico até o momento) projeto assim "de verdade, pra valer sabe rsrs". Talvez pq eu tenha feito tudo atraves de assistentes...ai eu não tinha muito controle sobre ele (o bidingNavigator)...por isso que tentar fazer a mão agora hehe... mas eu me viro daqui pra frente...

    Uma ultima pergunta. É sobre a arquitetura em tres camadas. Nos artigos que eu vi até agora, sempre foi criada uma classe para cada tabela no banco de dados... isso é realmente necessario? Assim eu tenho uma classe que acessa o banco de dados como já disse... mas você aconcelha sempre se fazer varias classes para o acesso a dados? Cada uma cuidando de uma "coisa" ? Não sei se fui claro dessa vez...

    Bom... muito obrigado pela ajuda. Você já me ajudou bastante até agora.


    Grande abraço.

    Att,

    Felipe.

    segunda-feira, 21 de julho de 2008 02:05
  • Vai do gosto... todos frameworks que fiz até hoje faziam classes espelhos de tabela na camada de dados, outros, como nHibernate também o fazem.

    Mas hoje em dia, com Linq to Sql e ADO.Net Entities, nem é necessário este trabalho...

    Pegue suas tabelas, arrasta para o designer e voi-lá... você tem suas entidades de dados prontas pra uso com Linq.

    E se quiser extendê-las, é fácil: as entidades do Linq são Partial Classes, então, só adicionar o que quer...

    ADO.Net Entities vai mais além e permite fazer mapeamentos mais complexos (não necessariamente espelho de tabelas), herança, etc...

    Se tiver a possibilidade de usar .Net 3.5, vá de Linq to Sql na sua camada de dados... (Isso é, se estiver usando MSSQL).
    segunda-feira, 21 de julho de 2008 02:11