O que o pessoal do forum acha da implementação da camada DAO em app Android?
E das famosas classes semelhantes a entity beans que contem somente métodos get/set para supostamente implementar corretamente a OO?
Na opinião de voces, Os padrões e práticas para desenvolvimento de app na plataforma JEE são de fato necessárias em uma app da plataforma Android?
Como estamos tratando de duas plataformas diferentes, recursos diferentes, poder computacional diferente etc.
Desenvolver para dispositivos móveis em geral é diferente de desenvolver em cima de uma plataforma web.
O pensamento em economizar memória, em escalar processos, economia de poder computacional.
Você pode aproveitar boa parte dos padrões, mas sempre pensando em economizar recursos.
[quote=immortalSoul]O que o pessoal do forum acha da implementação da camada DAO em app Android?
E das famosas classes semelhantes a entity beans que contem somente métodos get/set para supostamente implementar corretamente a OO?
Na opinião de voces, Os padrões e práticas para desenvolvimento de app na plataforma JEE são de fato necessárias em uma app da plataforma Android? [/quote]
Padrões sim…praticas não.
[quote=FernandoFranzini][quote=immortalSoul]O que o pessoal do forum acha da implementação da camada DAO em app Android?
E das famosas classes semelhantes a entity beans que contem somente métodos get/set para supostamente implementar corretamente a OO?
Na opinião de voces, Os padrões e práticas para desenvolvimento de app na plataforma JEE são de fato necessárias em uma app da plataforma Android? [/quote]
Padrões sim…praticas não.[/quote]
Nesse caso, o que jusitificaria o uso do padrão Facade ou um de um DAO em uma app android?
As próprias motivações documentadas nos padrões!!! Qual outra teria? kkkkk
As próprias motivações documentadas nos padrões!!! Qual outra teria? kkkkk[/quote]
Mas elas não se enquadram a arquitetura do android.
Veja o DAO, por exemplo, qual seria a necessidade de utilizar o DAO quando tenho um Content Provider?
Bom, vai minha opinião do assunto, veja se acrescenta algo para vc:
Tudo isso uma é questão de contexto, ou seja vc não enquadra, é o pattern simplesmente acontece!
Precisamos lembrar de algumas coisas quando se usa um pattern:
Veja o caso:
[quote]DAO Context
Access to data varies depending on the source of the data. Access to persistent storage, such as to a database, varies greatly depending on the type of storage (relational databases, object-oriented databases, flat files, and so forth) and the vendor implementation.
[/quote] http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
Exemplo1: Imagine um caso de vc desenvolver uma aplicação android que o mecanismos de persistência pode ser intercambial entre arquivos XML, Banco Relacional Local, File ou até um SGDB remoto? kkk DAO nele! E por ai vai…
Agora,…é claro que nem todos os padrões JEE serão aplicáveis pq são soluções com o perfil diferentes, mas que podem compartilhar contextos estruturais sim.
[quote=FernandoFranzini]Bom, vai minha opinião do assunto, veja se acrescenta algo para vc:
Tudo isso uma é questão de contexto, ou seja vc não enquadra, é o pattern simplesmente acontece!
Precisamos lembrar de algumas coisas quando se usa um pattern:
Veja o caso:
[quote]DAO Context
Access to data varies depending on the source of the data. Access to persistent storage, such as to a database, varies greatly depending on the type of storage (relational databases, object-oriented databases, flat files, and so forth) and the vendor implementation.
[/quote] http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
Exemplo1: Imagine um caso de vc desenvolver uma aplicação android que o mecanismos de persistência pode ser intercambial entre arquivos XML, Banco Relacional Local, File ou até um SGDB remoto? kkk DAO nele! E por ai vai…
Agora,…é claro que nem todos os padrões JEE serão aplicáveis pq são soluções com o perfil diferentes, mas que podem compartilhar contextos estruturais sim.[/quote]
Reconheço a importância para se trabalhar com os padrões de projetos quando se trabalha em java (principalmente JEE).
Mas veja só, um aplicativo android não é uma app enterprise.
Como voce citou, o DAO flexibiliza o acesso aos dados( algo importante para uma app enterprise), mas no Android temos o conceito de Content Provider, que é muito mais adequado ao ambiente android, considerando que a necessidade de migração de banco de dados é completamente desencorajado (e completamente desnecessário).
Um detalhe: O acesso a SGBD remoto é feito somente através de services, na verdade, web services.
Fica tranquilo que eu seu o conceito de Content Provider, eu tb trabalho com android....kkkk
[quote]considerando que a necessidade de migração de banco de dados é completamente desencorajado (e completamente desnecessário). [/quote]
A palavra certa seria incomun aqui e não "desencorajado"....mas eu tive projetos android com acesso JDBC sim para varias SGDB diferentes.
Vc pode dizer "desnecessário"para vc !!! para outros requisitos de outros cenarios talves não seja.
[quote]Um detalhe: O acesso a SGBD remoto é feito somente através de services, na verdade, web services. [/quote]
Aqui sou obrigado a descordar com vc....Web services é uma tecnologia com o único objetivo de integrar soluções e não de acessar um banco de dados.
A questão é de acessar um serviço externo sem conhecer detalhes internos....
Mais uma vez, humildemente vou te falar que: a suas experiências e os seus cenários podem não ser ideal para outras empresas, com outros cenarios e outros requisitos.Fica tranquilo que eu seu o conceito de Content Provider, eu tb trabalho com android…kkkk
A palavra certa seria incomun aqui e não “desencorajado”…mas eu tive projetos android com acesso JDBC sim para varias SGDB diferentes.
Vc pode dizer "desnecessário"para vc !!! para outros requisitos de outros cenarios talves não seja.
Aqui sou obrigado a descordar com vc…Web services é uma tecnologia com o único objetivo de integrar soluções e não de acessar um banco de dados.
A questão é de acessar um serviço externo sem conhecer detalhes internos…
Mais uma vez, humildemente vou te falar que: a suas experiências e os seus cenários podem não ser ideal para outras empresas, com outros cenarios e outros requisitos.
[quote=FernandoFranzini]Como voce citou, o DAO flexibiliza o acesso aos dados( algo importante para uma app enterprise), mas no Android temos o conceito de Content Provider, que é muito mais adequado ao ambiente android,
Fica tranquilo que eu seu o conceito de Content Provider, eu tb trabalho com android…kkkk
A palavra certa seria incomun aqui e não “desencorajado”…mas eu tive projetos android com acesso JDBC sim para varias SGDB diferentes.
Vc pode dizer "desnecessário"para vc !!! para outros requisitos de outros cenarios talves não seja.
Aqui sou obrigado a descordar com vc…Web services é uma tecnologia com o único objetivo de integrar soluções e não de acessar um banco de dados.
A questão é de acessar um serviço externo sem conhecer detalhes internos…
Mais uma vez, humildemente vou te falar que: a suas experiências e os seus cenários podem não ser ideal para outras empresas, com outros cenarios e outros requisitos.[/quote]
Poderia dar um exemplo de outro banco de dados relcional rodando diretamente em um dispositivo android?
Voce diz que faz acesso utilizando JDBC, mas imagino ser um banco de dados remoto, correto?
Sim! Velho e conhecido modelo Client/Server.
Sim! Velho e conhecido modelo Client/Server.[/quote]
Bom, até onde eu sei, todo ciclo de vida das aplicações androids são controladas pelo sistema, e com isso
um simples rotacionamento da tela poderia forçar uma ida ao banco de dados para recarregar as informações que estavam sendo editadas. ( Inclusive se a aplicação nao for bem escrita os dados podem se perder ou a aplicação pode se comportar de modo inesperado).
Como é possível um bom desempenho se a cada momento o dispositivo precisa fazer um acesso remoto?
O uso de JDBC não é recomendado, pelo menos isso foi o que eu li em alguns links pela internet.
esse link fala de alguns pontos, então não preciso citar aqui:
http://groups.google.com/group/android-developers/browse_thread/thread/f2d9504c7eec9baf
Ainda assim,
mesmo que o acesso via JDBC a um banco remoto em um dispositivo movel fosse viavel, não justificaria o uso do DAO para a maioria dos casos, pois esse seria mais uma exceção do que uma regra.
Um desenvolvedor android não precisa se preocupar com a mudança do banco sqlite para o access da vida da mesma forma que um desenvolvedor de aplicativos enterprise precisa se preocupar com a possível mudança de uma banco Oracle para um Postgresql. Sao situações diferentes e necessidades diferentes.
Se vc “não acha” bom, se vc “leu” por ai que não é bom, se vc como responsável arquitetural chegou nas suas conclusões…tudo bem querido!
Só que isso não quer dizer não seje boa para outro cenários.
Eu particularmente discordo de vc…acho uma opção super normal e bem viável desde que os requisitos apontem para isso.
Agora, qualquer aplicação mal projetada fica ruim…independente de plataforma ou tecnologia.
Eu como projetista/arquiteto acho que nós temos que estar preparada para solucionar qualquer cenário que apareça.
[quote=FernandoFranzini]Se vc “não acha” bom, se vc “leu” por ai que não é bom, se vc como responsável arquitetural chegou nas suas conclusões…tudo bem querido!
Só que isso não quer dizer não seje boa para outro cenários.
Eu particularmente discordo de vc…acho uma opção super normal e bem viável desde que os requisitos apontem para isso.
Agora, qualquer aplicação mal projetada fica ruim…independente de plataforma ou tecnologia.[/quote]
O ponto é: JDBC está mais como um substituto dos web services ( mas preciso concordar que é mais adequado ) do que o banco primario de uma aplicação android. O que quero dizer com isso é que independente de fazer acesso a outro banco, não posso descartar o sqlite para armazenar nem que seja o estado atual da minha app. Fazer um acesso remoto para gravar e recuperar informações no banco só por que mudei de posição meu display não é bom nem pro meu banco, nem pra minha rede e nem pro meu usuário. Pelo menos foi isso que entendi.
O meu ponto de vista é…JDBC é uma especificação para fazer uma coisa…WS é outra especificação para fazer outra…não existe equivalência de opção ou substituição! são especificações distantes e não concorrentes…
Do ponto de vista arquitetural…no sentido de se posicionar como “arquiteto/projetista” de software.
O meu ponto de vista é…JDBC é uma especificação para fazer uma coisa…WS é outra especificação para fazer outra…não existe equivalência de opção ou substituição! são especificações distantes e não concorrentes…
Do ponto de vista arquitetural…no sentido de se posicionar como “arquiteto/projetista” de software.
[/quote]
Substituto no sentido de realizar oprações de consulta, inclusão. alteração ou remoção de registros em um banco de dados remoto.
A própia citação que voce postou evidencia isso:
Claro que web services tem um conceito mais amplo ( na verdade diferente)
[quote]Substituto no sentido de realizar oprações de consulta, inclusão. alteração ou remoção de registros em um banco de dados remoto.
A própia citação que voce postou evidencia isso: [/quote]
Então brow (não sei seu nome)…isso ai é umas das piores gafs que alguem pode cometer…usar WS para fazer operações CRUD!. Ao contrario disso, Um “web service” é um serviço externo no qual sua aplicação quer se integrar. O objeto da tecnologia é encapsular a plataforma da solução A, fazendo acessível via HTTP para outras soluções parceiras de escritas em outras plataformas. Um web service corretamente implementando usa uma granulação alta e não baixa como CRUD, expondo serviços funcionais atômicos inerentes ao negocio. Mas isso dai ja sai completamente fora do foco do post aqui.
Por isso, que dizer…q se esta considerando JDBC ou WS para acesso ao banco de dados relacionais é algo que não faz sentido, inconsistente…mesmo que praticamente possa ser feita (e nós sabemos que tem gente q faz…kkkk)
[quote=FernandoFranzini][quote]Substituto no sentido de realizar oprações de consulta, inclusão. alteração ou remoção de registros em um banco de dados remoto.
A própia citação que voce postou evidencia isso: [/quote]
Então brow (não sei seu nome)…isso ai é umas das piores gafs que alguem pode cometer…usar WS para fazer operações CRUD!. Ao contrario disso, Um “web service” é um serviço externo no qual sua aplicação quer se integrar. O objeto da tecnologia é encapsular a plataforma da solução A, fazendo acessível via HTTP para outras soluções parceiras de escritas em outras plataformas. Um web service corretamente implementando usa uma granulação alta e não baixa como CRUD, expondo serviços funcionais atômicos inerentes ao negocio. Mas isso dai ja sai completamente fora do foco do post aqui.
Por isso, que dizer…q se esta considerando JDBC ou WS para acesso ao banco de dados relacionais é algo que não faz sentido, inconsistente…mesmo que praticamente possa ser feita (e nós sabemos que tem gente q faz…kkkk) [/quote]
Mas o que acontece com frequencia é algo que pode ser considerado um serviço de fato ( um web service mesmo), pois é uma sincronização de dados que tua aplicação android faz com um servidor remoto. Como essa sincronização não ocorre em tempo real, é uma solução bem razoavel. Por isso que no android normalmente a integração com outros bancos/sistemas é feito através de web services.
O acesso direto a um banco remoto, seja através de JDBC, seja através de web service não é uma boa ideia devido ao ‘conturbado’ ciclo de vida de uma aplicação android. O sistema está o tempo todo carregado e descarregado as activity e service da memoria. O acesso a um recurso remoto no android é recomendado ser feito através de services rodando em uma thread separada justamente para não atrapalhar a experiencia do usuário coma aplicação.
Mais alguém já implementou acesso a banco remoto sem utilizar um banco local?
Como fica a experiencia do usuário com isso? Nunca fiz, mas pelo que li na documentação ( em http://developer.android.com/) e pelo que entendi da arquitetura android me parece uma pessima solução pra qualquer situação.