Play Framework 2.0 será integrado ao pacote de ferramentas de desenvolvimento da Typesafe

Exagero a noticia nao ?

Boa noticia.

Mas ainda não ficou claro o que irá acontecer com o framework Lift, que tem o mesmo objetivo do Play.
Mas de qualquer forma é interessante essa noticia, da escolha do Play, que é um baita framework.

johnny quest:

Boa noticia.

Mas ainda não ficou claro o que irá acontecer com o framework Lift, que tem o mesmo objetivo do Play.
Mas de qualquer forma é interessante essa noticia, da escolha do Play, que é um baita framework.

Não irá acontecer nada com ele. Ele continua sendo uma outra opção de framework web scala, como tantas outras que existem.

Há uma thread na lista do lift sobre isto: Play as a part of Typesafe stack, what is Lift’s answer?, onde inclusive o David Polak fala que foi convidado para entrar para a Typesafe:

A Typesafe é apenas mais uma empresa, que adicionou um framework web ao seu stack!

Sobre o Play! 2.0, fiquei com vontade de dar uma olhada nele, nesta versão o suporte a Scala ficou nativo, antes era via plugin, inclusive parece que tem mais suporte a Scala do que java nesta versão.
Mas primeiro quero terminar meus estudos do Lift, para entao poder compara-los e escolher o que melhor me atende!

O bom do play é que tem um site mais amigavel e bem documentado, o Lift deixa a desejar um pouco neste quesito!

Gostei muito da notícia. A versão 2.0 do Play vai ser show de bola, mal posso esperar

Correndo o risco de gerar uma briga ao invés de uma discussão saudável, mas lá vai:

Sou o único preocupado com o tipo de código que esses frameworks Rails-like geram no longo prazo ?

A meu ver, usando esses frameworks que estimulam Active Record e esse excesso de responsabilidades em uma entidade*(mais um struct com acesso ao DB que uma entidade de fato) a tendência é ir fazendo algo cada vez menos OO, ao menos do ponto da coerência do objeto.

Sei que é possível fazer diferente com esses frameworks, mas dificilmente alguém vai, conscientemente selecionar um framework e fazer algo diferente dos moldes que ele propõe(sacrificando assim a tão divulgada produtividade).

Pela minha experiência grande parte dos grandes softwares surgem a partir de pequenas versões, então aquela idéia de que esses frameworks poderiam ser aplicados a projetos de menor parte também é perigosa.

Gostaria de ouvir a opinião de vocês, não sei se estou sendo purista demais.

Abs

GraveDigger:

Correndo o risco de gerar uma briga ao invés de uma discussão saudável, mas lá vai:

Sou o único preocupado com o tipo de código que esses frameworks Rails-like geram no longo prazo ?

A meu ver, usando esses frameworks que estimulam Active Record e esse excesso de responsabilidades em uma entidade*(mais um struct com acesso ao DB que uma entidade de fato) a tendência é ir fazendo algo cada vez menos OO, ao menos do ponto da coerência do objeto.

Sei que é possível fazer diferente com esses frameworks, mas dificilmente alguém vai, conscientemente selecionar um framework e fazer algo diferente dos moldes que ele propõe(sacrificando assim a tão divulgada produtividade).

Pela minha experiência grande parte dos grandes softwares surgem a partir de pequenas versões, então aquela idéia de que esses frameworks poderiam ser aplicados a projetos de menor parte também é perigosa.

Gostaria de ouvir a opinião de vocês, não sei se estou sendo purista demais.

Abs

O Play não sei pq nunca estudei, mas o Lift oferece 3 opções de camada de persistencia: Record, Mapper(Esta dizem ser parecida com o Active Record: " At a high level, Mapper takes a design direction that is similar, but not
completely truthful to the Active Record pattern") e JPA.

A indicada como mais robusta é o Record, mas falam que para a maioria dos casos de apps pequenos e tals, voce pode começar com Mapper que da conta do recado.

fredferrao:

GraveDigger:

Correndo o risco de gerar uma briga ao invés de uma discussão saudável, mas lá vai:

Sou o único preocupado com o tipo de código que esses frameworks Rails-like geram no longo prazo ?

A meu ver, usando esses frameworks que estimulam Active Record e esse excesso de responsabilidades em uma entidade*(mais um struct com acesso ao DB que uma entidade de fato) a tendência é ir fazendo algo cada vez menos OO, ao menos do ponto da coerência do objeto.

Sei que é possível fazer diferente com esses frameworks, mas dificilmente alguém vai, conscientemente selecionar um framework e fazer algo diferente dos moldes que ele propõe(sacrificando assim a tão divulgada produtividade).

Pela minha experiência grande parte dos grandes softwares surgem a partir de pequenas versões, então aquela idéia de que esses frameworks poderiam ser aplicados a projetos de menor parte também é perigosa.

Gostaria de ouvir a opinião de vocês, não sei se estou sendo purista demais.

Abs

O Play não sei pq nunca estudei, mas o Lift oferece 3 opções de camada de persistencia: Record, Mapper(Esta dizem ser parecida com o Active Record: " At a high level, Mapper takes a design direction that is similar, but not
completely truthful to the Active Record pattern") e JPA.

A indicada como mais robusta é o Record, mas falam que para a maioria dos casos de apps pequenos e tals, voce pode começar com Mapper que da conta do recado.

A versão atual é focada principalmente na produtividade. Creio que o framework estabelecerá uma boa relação entre as características de qualidade de código/arquitetura/design e produtividade na próxima versão (2.0).

[]'s

GraveDigger:

Sou o único preocupado com o tipo de código que esses frameworks Rails-like geram no longo prazo ?

A meu ver, usando esses frameworks que estimulam Active Record e esse excesso de responsabilidades em uma entidade*(mais um struct com acesso ao DB que uma entidade de fato) a tendência é ir fazendo algo cada vez menos OO, ao menos do ponto da coerência do objeto.

Quando eu programo Java eu uso os famosos DAOs, mas qual o problema do ActiveRecord?. Eu gosto muito de Rails e acho esse padrão (ActiveRecord) infinitamente superior. Eu não consigo entender como alguém que já usou as facilidades do Rails como o Arel, Named Scopes, Validações e Nested Attributes. prefere usar DAOs. O código com Rails fica muito mais elegante, enxuto e reutilizável. Por isso eu vejo com bons olhos esses frameworks que visam trazer isso pro Java

Desde quando Entidade rica é menos OO? Pra mim menos OO é entidade com com propriedades públicas e mais nada. Separar em camadas não significa OO. Até em C vc cria um Struct com propiedades públicas e cria uma camada pra acessar ele no banco

Adelar:

fredferrao:

O Play não sei pq nunca estudei, mas o Lift oferece 3 opções de camada de persistencia: Record, Mapper(Esta dizem ser parecida com o Active Record: " At a high level, Mapper takes a design direction that is similar, but not
completely truthful to the Active Record pattern") e JPA.

A indicada como mais robusta é o Record, mas falam que para a maioria dos casos de apps pequenos e tals, voce pode começar com Mapper que da conta do recado.

A versão atual utiliza JPA para a persistência, mas a idéia é que na versão 2.0 qualquer tipo de persistência seja possível (mesmo de bancos não relacionais).

A versão atual é focada principalmente na produtividade. Creio que o framework estabelecerá uma boa relação entre as características de qualidade de código/arquitetura/design e produtividade na próxima versão (2.0).

[]'s

O record do Lift faz isto, na verdade ele é meio que uma especificação, no core do lift ja vem implmentado record para MongoDB, CouchDB e Squeryl, este ultimo suporta uma variedade de DB’s: Supported Databases