• Revista PROGRAMAR: Já está disponível a edição #53 da revista programar. Faz já o download aqui!

greed

InstantRails

13 mensagens neste tópico

No outro dia pus-me a brincar com o Ruby On Rails, e saquei o InstantRails pa Windows.

Achei um bocado fraco, nem installer tinha.

Vejam aqui: http://instantrails.rubyforge.org/wiki/wiki.pl

Já agora aproveito para lançar achas pa fogueira: Java ou Ruby? Qual o melhor?

Já li muitas opiniões e basicamente a discussão acaba sempre na facilidade de programação. Qual a vossa opinião? Há lago mais?

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Já agora aproveito para lançar achas pa fogueira: Java ou Ruby? Qual o melhor?

Em que campo?
0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Como normalmente se discute a ease-of-use do Ruby versus Java, gostaria de aqui discutir também RoR vs Java (três tiers - suponhamos: stripes+J2EE+Hibernate) em termos de arquitectura destes 2 tipos de solução.

EDIT: acho que respondi à tua pergunta

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

São coisas difíceis de comparar, aliás, ao indicares as 3 camadas já escolhes duas tecnologias que poderão influenciar a comparação. Já não é RoR vs. Java :D

Acho que possuem propósitos diferentes e não penso que seja útil comparar as duas de forma abstracta. A comparar, seria mais de acordo com uma avaliação pontual das duas tecnologias quando aplicadas a um determinado problema.

No entanto as diferenças conceptuais das duas tecnologias, RoR e JEE são minimas, situando-se mais na componente MVC. Tudo depende muito do tipo de tecnologia que usas nesse ponto, por exemplo, o sistema de action do RoR é diferente do do Structs, mas em JEE, para substituires o Structs possuis imensas frameworks diferentes o que, novamente, torna a comparação muito limitada.

Este é um artigo que li há uns tempos e que penso que é interessante leres, http://www.ibm.com/developerworks/web/library/wa-rubyonrails.

Mas acho que RoR é uma framework nova, apesar de baseada numa linguagem que considero de qualidade, enquanto que JEE é algo que está mais utilizado. E esse talvez seja o ponto mais importante, qual das duas tecnologias é mais usada? Não falando das qualidades de uma ou outra, que penso dependerem muito de projecto para projecto, JEE é uma tecnologia mais usada, sendo Structs a àrea onde existem mais oferta de empregos, mas estou provavelmente a desviar-me do assunto :(

Bem, para deixar assente a minha posição, acho que comparar as tecnologias sem ser num caso muito específico é inútil, o que pode ser bom num projecto pode ser mau noutro, a escolha da tecnologia deve ser feita com base nos requisitos e não no que o programador acha que é melhor ou pior, por isso não acho muito importante comparar duas tecnologias como penso que pretendias.

Cumprimentos.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Mas podes comparar duas arquitecturas (atenção que a solucao stripes/struts + J2SE + Hibernate supoe k tens um webserver e um SGBD quaisquer -> senao n tinhas um 3 tier...) em determinadas situacoes e olhando para poucos atributos de qualidade, por exemplo:

- atributos de qualidade: performance e escalabilidade

- cenários:

  - muitos pedidos ao servidor e poucos pedidos envolvem acessos à BD.

  - muitos pedidos ao servidor e muitos pedidos envolvem acessos à BD.

  - poucos pedidos ao servidor e poucos pedidos envolvem acessos à BD.

  - poucos pedidos ao servidore e muitos pedidos envolvem acessos à BD.

Assim já dá para fazer uma melhor comparação em termos arquitecturais não achas? Pode-se considerar como factores importantes de comparação: o número de conversões, a maneira cm e' tratada a concorrência e a utilização de caches.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Mas isso são questões que não estão afectas ao JEE mas sim à solução que escolheste, neste caso o uso de hibernate, do servidor aplicacional e do SGBD que usares.

Nem sempre a base de dados tem de ser relacional, nem sempre tens de usar Hibernate para acederes a persistências relacional, até a forma como usares o hibernate, por exemplo em coisas tão simples como a escolha entre ficheiros de propriedades ou anotações, tem influência, e isso não é de JEE mas sim das tecnologias que estas a usar como apoio.

E podes ter 3 tier sem esses componentes, 3 tier é um arquitectura, é independente da tecnologia que usas por trás, podes não usar um servidor web, nem um SGBD e ainda teres 3 tier. Por exemplo, MVC pode ser visto com 3 tier, existem 3 camadas distintas na implementação do padrão aplicacional MVC e em nenhuma dessas camadas precisas estar um servidor web ou o que seja.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Boas, ent mas eu tou a agr tou a dzr para compararem p este caso especifico.

Tb n diria tecnologias de apoio ao J2SE...o hibernate neste caso é o Data access layer, ou seja, uma camada essencial.

Explica la melhor isso do MVC ser 3 tier, é q o RoR usa o padrão arquitectural MVC mas isso n dispensa os outros 2 componentes da arquitectura de existirem: web server e BD. A solução Stripes+J2SE+Hibernate que aqui apresentei é a mesma coisa: necessitas de um web server e tb de uma BD.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Dizer 3 tier, ou 3 camadas é apenas uma forma de indicar como está feita a arquitectura da aplicação. 3 camadas é apenas um nome que se dá a uma aplicação com 3 pontos distintos, normalmente fala-se no caso de aplicações empresariais em que as 3 camadas definem interface, lógica de negócio e persistência, mas não tem de ser assim, 3 camadas são 3 camadas em qualquer aplicação que as implemente.

Pegando no caso de uma aplicação MVC, isso implica que existe um modelo, uma vista e um controlador, ou se quiseres pensar de outra forma, uma camada para as vistas, uma camada para o modelo e uma camada para os controladores, logo 3 camadas :D.

No caso do RoR, ou de outra tecnologia que se utilize para desenvolver aplicações empresariais, MVC é algo que se deve usar não algo que seja obrigado, apesar da framework providenciar mecanismos para isso, o que posso dizer em relação a isso é que uma aplicação empresarial, seja RoR ou não, deve usar o modelo n-camadas, e ao mesmo tempo implementar o padrão MVC.

Talvez não me tenha explicado... Em RoR podes dispensar o modelo 3 camadas tal como podes dispensar o modelo MVC, e no meio de tudo isso nada te diz que MVC não é 3 camadas, repara que 3 camadas é uma arquitectura que apenas te indica que a aplicação tem de ser feita em 3 camadas, mas não fala do nível de detalhe, podes ver cada uma dessa 3 camadas individualmente e cada uma delas ser implementada numa arquitectura que faça sentido e assim tens 3 camadas dentro de 1 camada de um modelo de 3 camadas, confuso? :D

Quanto ao exemplo, não foi nada de específico, é apenas um exemplo que serve para todo o tipo de projectos. Ser escalável, possuir boa performance. Quanto aos pontos de acesso à base de dados, problemas de cache, etc, não é algo que seja resolvido pelo uso de RoR, ou prejudicado pelo uso de JEE.

O Hibernate não é uma camada essencial, faz parte da camada de acesso a dados. Se ignoramors a camada de apresentação e a camada de modelo de negócio, numa aplicação 3 camadas, tipicamente sobra a de acesso a dados. Essa camada pode ser implementada das mais variadas maneiras, com ou sem uso de Hibernate. Por exemplo, Hibernate pode ser substituido por TopLink ou por JPA, que implementam de formas diferentes o sistema de cache, por exemplo. Ou até remover o acesso a dados relacionais, a camada de dados pode ser conseguida com db4o ou com a simples serialização e uso de POJOs.

Quando falo em exemplos específicos falo em problemas reais onde entram questões como tipo de utilizadores, tipo de máquinas disponíveis, tipo de contracto,  manutenções, acompanhamento do sistema, objectivos do sistema, ambiente onde o sistema vai operar.

Um exemplo, a escolha entre GWT e o projecto Woodstock para a implementação da interface de um sistema empresarial foi decido com base no tempo e não na capacidade de cada uma tecnologias, era mais lento usar GWT, seja melhor ou não, e os prazos têm de ser cumpridos, logo, os componentes Woodstock foram a escolha. Neste caso as caracteristicas das tecnologias foram tidas em conta de forma muito leviana, não interessou saber se os componentes Woodstock são melhores que o GWT. Ponderados os pontos, o que mais peso apresentou foi o facto de que o projecto ser para estar pronto daqui a 30 dias.

Compreendo o que queres fazer mas sinceramente não penso que seja importante ou até muito útil, e em grande parte dos casos vai ser complicado fazer uma avaliação objectiva, existe sempre a "opinião" do programador que usou mais uma tecnologia ou outra, o que nunca teve problemas e acha a tecnologia uma maravilha e não consegue compreender os problemas que os outros têm, etc.

No entanto se alguém quiserer avançar mais opiniões sobre as duas tecnologias gostava de as ouvir :(

Cumprimentos.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

O Hibernate não é uma camada essencial, faz parte da camada de acesso a dados. Se ignoramors a camada de apresentação e a camada de modelo de negócio, numa aplicação 3 camadas, tipicamente sobra a de acesso a dados. Essa camada pode ser implementada das mais variadas maneiras, com ou sem uso de Hibernate. Por exemplo, Hibernate pode ser substituido por TopLink ou por JPA, que implementam de formas diferentes o sistema de cache, por exemplo. Ou até remover o acesso a dados relacionais, a camada de dados pode ser conseguida com db4o ou com a simples serialização e uso de POJOs.

O Hibernate e' essencial se for do tipo "full cream"...é como se o hibernate fosse a data access layer. EDIT: é essencial na arq. que eu referi até pq faz parte dela lol...fica um bcado mal dito assim  :-[

Compreendo o que queres fazer mas sinceramente não penso que seja importante ou até muito útil, e em grande parte dos casos vai ser complicado fazer uma avaliação objectiva, existe sempre a "opinião" do programador que usou mais uma tecnologia ou outra, o que nunca teve problemas e acha a tecnologia uma maravilha e não consegue compreender os problemas que os outros têm, etc.

Eu não queria falar muito do ponto de vista do programador, pois esse preocupar-se-á com aspectos do género: é fácil de implementar, linguagem que gosto mais etc. Eu queria discutir isto do ponto de vista de um arquitecto de software, que tem determinados atributos de software que tem que cumprir e conciliar (pois os stakeholders são chatos  :D) numa arquitectura dum sistema. Neste caso, tendo cm requisitos a performance e a escalabilidade, eu faria as seguintes atribuições:

• Muitos pedidos ao web-server e muitos pedidos envolvem acessos à BD.

Neste caso, a opção Stripes + J2SE + Hibernate é a melhor porque dispõe de varios niveis de cache. O Hibernate usa sempre a cache de 1º nivel, e deste modo previne multiplas idas à BD par ao mesmo objecto. Usando uma cache de 2º nivel pode permiter grande parte da BD estar alocada em memória, o que é util para dados frequentemente lidos e referenciados. Isto apesar de neste tipo de arq. ser necessario efectuar um maior numero de conversoes que no RoR.

• Muitos pedidos ao web-server e poucos pedidos envolvem acessos à BD.

Neste caso, o RoR tem uma melhor performance porque implementa uma cache na 'presentation layer'. E o Stripes + J2SE + Hibernate não o faz.

• Em relação ao topic "poucos pedidos ao web-server", acho que as duas arq. são más. Preferia LAMP nesse caso.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Parece-me que vemos as coisas a nível de conceitos de forma diferente o que torna mais complicado expressar-mos as ideias. Mas penso que estou a perceber a tua, apesar de, se a estiver a perceber bem, não concordar muito.

"Muitos pedidos ao web-server e muitos pedidos envolvem acessos à BD": optimização da base de dados, desnormailzação, uso de webserver correcto para o objectivo, repensar o sistema dado que muitos pedidos que envolvam muitos pedidos à base de dados podem ser um problema.

Em relação ao topic "poucos pedidos ao web-server", acho que as duas arq. são más. Preferia LAMP nesse caso

LAMP? Isso não é Linux-Apache-MySQL-PHP? é que se for estás a misturar um pouco as coisas. JEE ou RoR não implicariam menos performance e a nível de escalabilidade tomo qualquer servlet a um script PHP :D

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites
Em relação ao topic "poucos pedidos ao web-server", acho que as duas arq. são más. Preferia LAMP nesse caso

LAMP? Isso não é Linux-Apache-MySQL-PHP? é que se for estás a misturar um pouco as coisas. JEE ou RoR não implicariam menos performance e a nível de escalabilidade tomo qualquer servlet a um script PHP :D

Se forem pedidos esporádicos...ou seja o objecto de procura não se encontra em memória e terá que ser feita uma ida à BD para buscar o objecto. O LAMP é bem mais rápido que as outras duas arq. visto que faz logo o acesso à BD no php. O RoR e o Stripes + J2SE + Hibernate têm mais overhead até por fazerem mais conversões de parâmetros. O LAMP para pedidos esporádicos torna-se então uma boa alternativa.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

A ideia dessa frase era mesmo a "servlet" que nada tem a ver com Stripes+JEE+Hibernate :D

O que disse foi que, para mim, antes uma servlet que qualquer solução que envolva PHP.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

A ideia dessa frase era mesmo a "servlet" que nada tem a ver com Stripes+JEE+Hibernate :D

O que disse foi que, para mim, antes uma servlet que qualquer solução que envolva PHP.

Pronto, é a tua opinião, fica a ideia então que só conseguiamos provar que uma solução arquitectural é melhor que a outra com testes. A ideia desta thread além de saber o que vcs achavam do RoR (ja agr o InstantRails), e dps também ver algumas divergências que eventualmente houvesse entre as duas arq. descritas atrás..

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!


Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.


Entrar Agora