Vale a pena? ultilizar frameworks ?

[Marcelo Garbin 30]

 

Pois então, lendo todos os fatos, lá vai minha opinião:

 

Requisitos para se desenvolver um framework:

 

- Conhecimento

- Iniciativa

 

Sigo com a opinião do @Alaerte, aprendi PHP assim, tendo iniciativa, vontade, buscando conhecimento, e hoje com Framework não é diferente, depois de ler o que o @Rudy_jr passou fiquei bem mais interessado e curioso, hoje pela manhã resolvi começar a ler a respeito e pelos Framework's citados eu resolvi começar com o Cake PHP, até por que o @thiagobelem também indica e acho esse cara um dos feras no PHP.

 

Por onde comecei:

 

http://book.cakephp.org/1.3/pt/The-Manual/Beginning-With-CakePHP.html

 

O @Enrico me alertou sobre material anterior estar defasado, não havia me tocado disso, mesmo assim consegui configurar o Cake PHP.

 

Segue o link da versão 2.x:

 

http://book.cakephp.org/2.0/pt/index.html

 

Até agora fiz a configuração do Cake, e parece que ficou tudo certo :clap:

 

 

Também vi esse texto: http://forum.imasters.com.br/topic/366132-tutorial-iniciando-no-cakephp/

 

e vou ver esse vídeo depois que terminar de ler a documentação do Cake: http://www.pinceladasdaweb.com.br/blog/2012/09/05/comecando-com-cakephp-blog-simples-crud-1/

 

Espero que eu esteja no caminho certo! Se eu não estiver por favor alguém me corrija! :graduated:

 

E para o alto e sempre avante! :thumbsup:

 

 

#56:

 

Tecnicamente, MVC não é um design pattern, mas um modelo de desenvolvimento (architecture pattern). :D

 

Ao citar PDO, eu quis dizer como usar PDO. Ao citar ORM e AL eu quis dizer como implementar (como funciona, qual a lógica, etc).

 

 

Como assim "Técnicamente o MVC não é design pattern"?

 

Olha o que diz no site do Cake PHP:

 

"Por que usar MVC? Porque é um verdadeiro padrão de projeto (design pattern) e torna fácil a manutenção da sua aplicação, com pacotes modulares de rápido desenvolvimento."

 

Mais informações em: http://book.cakephp.org/1.3/pt/The-Manual/Beginning-With-CakePHP/Understanding-Model-View-Controller.html

 

É isso gurizada...

[Enrico Pereira 299]

Aprenda uma coisa: frameworks adoram fazer marketing e colocar palavras bonitinhas para atrair. MVC é um design pattern arquitetural (ou padrão de arquitetura), que não está estritamente relacionado com orientação a objetos, MVC pode ser implementado em qualquer paradigma, etc., ele apenas define uma "separação".

[Marcelo Garbin 30]

Aprenda uma coisa: frameworks adoram fazer marketing e colocar palavras bonitinhas para atrair. MVC é um design pattern arquitetural (ou padrão de arquitetura), que não está estritamente relacionado com orientação a objetos, MVC pode ser implementado em qualquer paradigma, etc., ele apenas define uma "separação".

 

OK, @Enrico, mas isso que você falou pra mim é o mesmo que citei anteriormente e que esta na documentação do Cake PHP.

 

"Por que usar MVC? Porque é um verdadeiro padrão de projeto (design pattern) e torna fácil a manutenção da sua aplicação, com pacotes modulares de rápido desenvolvimento."

 

Nessa frase não esta dizendo nada que a aplicação é o Cake ou X Framework, acho que isso é em geral, eu já conhecia MVC pois usei em Java, mas obrigado pela resposta, com certeza irá ajudar outras pessoas a definir melhor MVC. :joia:

[Enrico Pereira 299]

MVC é um padrão de projeto. Pois um padrão de projeto pode ser um design pattern, um padrão de arquitetura, etc.

 

A tradução de design pattern para padrão de projeto é totalmente equivocada e causa confusões. Design patterns fazem parte dos padrões de projeto, mas padrões de projeto não se resumem aos design patterns, e portanto, chamar design pattern de padrão de projeto é errado.

 

O que eu falei foi que o MVC é um design pattern arquitetural, ou melhor chamado: padrão de arquitetura (de código).

 

Esse erro é muito mas muito comum: chamar MVC de design pattern.

 

Design pattern => solução reutilizável para um problema usando Orientação a Objetos (Factory Method, Composite, Command, etc.)

Padrão arquitetural => solução reutilizável para separar camadas (MVC, MVP, etc.)

 

http://pt.wikipedia.org/wiki/MVC (que feio...... :()

http://pt.wikipedia.org/wiki/Padr%C3%A3o_de_projeto_de_software ( :o)

 

MVC não :no: é um design pattern.

[Micilini Roll 49]

interessante pessoal,eu ja vi na net muitos tutoriais de como se criar um framework ! acho que vale a pena sim...

[Alaerte Gabriel 662]

interessante pessoal,eu ja vi na net muitos tutoriais de como se criar um framework ! acho que vale a pena sim...

 

Se for a nível de conhecimento e uso próprio, vale sim. Mais para concorrência, não vale, ao meu ver.

[Enrico Pereira 299]

Eu acho que vale se for muito bem planejado.

[Henrique Barcelos 290]

Padrão arquitetural => solução reutilizável para separar camadas (MVC, MVP, etc.)

Calma lá, nem todo padrão arquitetural tem por premissa separar camadas.

 

Vamos parar de complicar as coisas.

A tradução livre de Design Pattern é sim "Padrão de Projeto".

 

Entretanto, existem padrões de projeto a nível de Engenharia de Software, que são mais "baixo nível", dizem respeito ao código em si e como implementá-lo. São comumente chamados de padrões, padrões de projeto ou design patterns.

 

Também existem padrões de projeto a nível de Arquitetura de Software, que são mais "alto nível", dizem respeito à organização e interação dos componentes do sistema. São comumente chamados de padrões arquiteturais ou architectural design patterns.

 

O MVC se encaixa neste último caso. Utilizar o padrão arquitetural MVC pode implicar usar padrões como Observer, Chain of Responsibility, DAO, TDG, RDG, etc, etc, etc.

[Evandro Oliveira 331]

Dao, seria uma maneira inteligente de trabalhar em um framework?

Tanto em um quanto fora de um. Quando bem implementado, tudo que traz um acrônimo contendo um A=abstraction é uma maneira inteligente.

 

sendo que o usuário teria que criar e manipular vários objetos que seriam as tabelas mapeadas.

Eu penso em entidades e relacionamentos entre objetos. Tenho a tabela usuario que vai ser mapeada para instâncias da classe [inline]User[/inline], porque não realizar o mapeamento e ter uma entidade??

 

E vai na mesma linha: frameworks fazem marketing e querem que você use tudo dele e somente dele. Bem, é complexo, eu acho que frameworks que são uma coisa só são uma porcaria, pois eles são como um deus supremo que resolve tudo. É por isso que eu prefiro bibliotecas ou frameworks baseados em componentes (como ZF2 e Symfony2). Com esse tipo de framework, você resolve os problemas que precisa, não um trambolho que te dá um monte de coisas, muita das vezes inúteis.

Eu adorei esta parte do comenário, simplesmente por causa do eu prefiro :clap:.

 

É bem diferente de "não use X, Y porque são ruins, mal arquiteturados, cheios de gambiarra e favorecem Anti-Patterns..."

 

Você esqueceu do terceiro passo do TDD: a refactoring. Criar código bom "de primeira" é difícil e menos produtivo, quando você tem um código pronto com os testes (para poder confiar que a refactoring não quebra) é mais fácil executar uma refactoring, além de que você vai ter todo o foco para a refactoring.

TDD implica escrever testes. Escrever testes não implica TDD. Posso ter testes bem escritos, uma b... de implementação só pro teste passar e esperar a bomba explodir. A propósito, sabemos o quanto é comum.

Ao citar PDO, eu quis dizer como usar PDO. Ao citar ORM e AL eu quis dizer como implementar (como funciona, qual a lógica, etc).

A implementação de um ORM é um tanto complexa. Acho que dá pra dominar todos os frameworks de destaque no mercado e ainda ser um completo desconhecido dos ORM.

 

#56:

 

Tecnicamente, MVC não é um design pattern, mas um modelo de desenvolvimento (architecture pattern). :D

MVC é um padrão de projeto. Pois um padrão de projeto pode ser um design pattern, um padrão de arquitetura, etc.

 

A tradução de design pattern para padrão de projeto é totalmente equivocada e causa confusões. Design patterns fazem parte dos padrões de projeto, mas padrões de projeto não se resumem aos design patterns, e portanto, chamar design pattern de padrão de projeto é errado.

 

O que eu falei foi que o MVC é um design pattern arquitetural, ou melhor chamado: padrão de arquitetura (de código).

 

Esse erro é muito mas muito comum: chamar MVC de design pattern.

Senhores, eu pensei em - mais ou menos - um milhão de formas diferentes de responder a este ponto de vista.

 

Como primeira abordagem, vou ficar com a forma simplista de resposta

design

de.sign

(dizáin) sm (ingl) 1 Concepção de um projeto ou modelo; planejamento.

http://michaelis.uol.com.br/moderno/portugues/index.php?lingua=portugues-portugues&palavra=design

design {substantivo} -- projeto {m.} [bras.]

http://pt.bab.la/dicionario/ingles-portugues/design

 

design n (conception) projeto, desenho sm

http://www.wordreference.com/enpt/design

 

s. plano; desenho, esboço; propósito, objetivo

http://translation.babylon.com/english/to-portuguese/design/

 

Projeto

http://www.bing.com/translator/?to=pt&text=Design

 

Projeto

http://translate.google.com/#en/pt/Design

 

Babelfish, antigo tradutor do Yahoo, não funciona mais.

 

Me coloco à disposição para debate, uma vez que existe literatura didática para embasamento, também.

[Enrico Pereira 299]

Eu concordo, existem outros diversos tipos padrões arquiteturais.

 

Essa tradução é errônea pois em um projeto há diversos tipos de padrões.

 

Eu gosto de architectural design patterns, me parece mais coeso.

[Henrique Barcelos 290]

Não é o fato de você gostar que te faz estar certo...

[Enrico Pereira 299]

Meio óbvio Henrique... :lol: e você até falou sobre isso. Eu acho mais coesa (e gosto) pois diz bem à respeito: um design pattern de arquitetura, e não simplesmente padrão de arquitetura, que é uma nomenclatura mais genérica.

 

---

 

Evandro, uma pergunta besta e óbvia: quando você ouve a palavra "design" você pensa em projeto por acaso?

apesar de ser traduzível, não é o que mais faz sentido, o significado mais próximo da palavra design no contexto de design patterns é modelagem. Uma excelente tradução seria Padrões de Modelagem de Software e não Padrões de Projeto de Software.

 

Padrões de Projeto é uma palavra válida, mas não se resume somente à design patterns. Padrões de Projeto, na verdade, seria a tradução para project patterns.

[Evandro Oliveira 331]

Evandro, uma pergunta besta e óbvia: quando você ouve a palavra "design" você pensa em projeto por acaso?

Sinceramente, isolada assim, penso em arte gráfica. Penso em layout, disposição, cores, enfim, o design que o designer projetou.

apesar de ser traduzível, não é o que mais faz sentido

De fato, há muitas gírias e expressões nos mais diversos idiomas que não condizem com seu significado morfológico|etimológico.

 

Recentemente, lendo uma questão de matemática em inglẽs, derrapei na palavra saw. A mesma, mesmíssima palavrinha, estas 3 letras, pode significar serrote e visto. Tudo a ver, né?

o significado mais próximo da palavra design no contexto de design patterns é modelagem.

Voltando ao contexto de desenvolvimento de software, modelagem é um dos participantes do projeto.

 

A palavra projeto, remete à projeção. Projetar.

 

Tenho como entendimento pessoal de projetar como algo que se vê à frente. Mas, via dicionário, um significado dentro do contexto é planejar.

 

Um sinônimo para projetar é arquitetar e é exatamente da arquitetura que vem o termo design pattern.

 

Em 1977, Christopher Alexander, em parceria com mais alguns outros notáveis, publicou o livro A Pattern Language.

 

A partir deste ponto, padrões de arquitetura de software, ou qualquer derivado, torna-se redundante, uma vez que o termo provém da disciplina homônima.

 

Seguindo a mesma linha de raciocínio, teríamos que segmentar em padrões de arquitetura de software, padrões de engenharia de software, padrões de qualidade de software, padrões de usabilidade e acessibilidade de software, enfim.

Uma excelente tradução seria Padrões de Modelagem de Software e não Padrões de Projeto de Software.

Como já supra citado, é o projeto que compreende a modelagem, e não a modelagem que compreende o projeto. Alterar o projeto altera a modelagem. Design patterns trazem consigo, na maioria das vezes, uma notação de modelagem. Design patterns podem, eventualmente, interferir na modelagem de dados.

Padrões de Projeto é uma palavra válida, mas não se resume somente à design patterns. Padrões de Projeto, na verdade, seria a tradução para project patterns.

Dessa sua forma de pensar eu, definitivamente, desisto. Pra mim, são sinônimos.

[Henrique Barcelos 290]

Agora estamos discutindo semântica... ehuehehehuhu

[Bruno Augusto 417]

Agora estamos discutindo semântica... ehuehehehuhu

 

Culpa do inglês, um idioma preguiçosamente sustentável.

[Micilini Roll 49]

Culpa do inglês, um idioma preguiçosamente sustentável.

 

 

isso é!

[Alaerte Gabriel 662]

yes my friend

[Micilini Roll 49]

Ja acabou pessoal?! sera que agora poderemos fazer uma conclusão total juntando tudo de uma vez?

 

falando sobre quais sao os melhores frameworks quais sao os piores e os beneficios e contras de cada um,poste tambem qual tipo de framework voce usa!

[Alaerte Gabriel 662]

Lá vamos nós de novo...

[Micilini Roll 49]

nao nao alarte dessa vez nos iremos expor nossas opnioes o que cada um usa seus pos e seus contras,isso nao so ira me ajudar a qual melhor caminho devo seguir mais tambem outras pessoas que iram visitar este post,devera ser feito da seguinte maneira:

 

Framawork ultilizado: cakePHP

 

Caracteristicas/funcionabilidades

 

1. ele cria banco de dados em um clique
2. ele tem funçao de json
3. ele tem bla bla bla

 

Pos: ele é muito interessante ele é muito legal ele faz bla bla bla...

 

Contras: ele é bastante confuso,nao apresenta muitos beneficios de segurança e bla bla bla....

 

Conclusão: eu sou um pequeno programador,estou nessa area a mais de 3 anos e com o cakephp me facilita muito nao tenho do que reclamar e bla bla bla...

 

 

entendem pessoal somente isso!