Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Bom dia caros amigos da comunidade, gostaria de uma dica para saber se estou no caminho certo do mvc e se os meus métodos de organização estão da maneira certa, não gostaria de depender de frameworks então estou montando minha própria estrutura, me baseio a uma idéia do java usando vraptor (um framework brasileiro excelente JAVA), minha estrutura de diretórios montei assim. Não estou utilizando nenhum gerenciador de templates vou utilizar algumas funçoes próprias para isso, como disse quero algo independente
/applications/core/interface/imageproxy/imageproxy.php?img=http://img703.imageshack.us/img703/9374/pastas.jpg&key=5511c7332feb55486198f94b00108036fc26dc3e945d2cac3728702a9311d79b" alt="pastas.jpg" />
Vou postar alguns códigos de exemplos de como na minha concepção deveria ser
Classe Bean[ENTIDADES]
<?php
class Usuario
{
#Atributos
private $IDUSUARIO = null;
private $EMPRESAID = null;
private $NOME = null;
private $USUARIO = null;
private $SENHA = null;
private $NOMEPERFILID = null;
private $REGEXC = null;
private $PERMISSAOTOTAL = null;#Getters e Setters
public function getIDUSUARIO(){
return $this->IDUSUARIO;
}
public function setIDUSUARIO($IDUSUARIO){
$this->IDUSUARIO = $IDUSUARIO;
}
public function getEMPRESAID(){
return $this->EMPRESAID;
}
public function setEMPRESAID($EMPRESAID){
$this->EMPRESAID = $EMPRESAID;
}
public function getNOME(){
return $this->NOME;
}
public function setNOME($NOME){
$this->NOME = $NOME;
}
public function getUSUARIO(){
return $this->USUARIO;
}
public function setUSUARIO($USUARIO){
$this->USUARIO = $USUARIO;
}
public function getSENHA(){
return $this->SENHA;
}
public function setSENHA($SENHA){
$this->SENHA = $SENHA;
}
public function getNOMEPERFILID(){
return $this->NOMEPERFILID;
}
public function setNOMEPERFILID($NOMEPERFILID){
$this->NOMEPERFILID = $NOMEPERFILID;
}
public function getREGEXC(){
return $this->REGEXC;
}
public function setREGEXC($REGEXC){
$this->REGEXC = $REGEXC;
}
public function getPERMISSAOTOTAL(){
return $this->PERMISSAOTOTAL;
}
public function setPERMISSAOTOTAL($PERMISSAOTOTAL){
$this->PERMISSAOTOTAL = $PERMISSAOTOTAL;
}
}
?>Classe DAO[UsuarioDao]
<?php
class UsuarioDao {
private $_Conexao = null;
private $_Usuario = null;
public function __construct(){
$this->_Conexao = DB::getInstance();
$this->_Usuario = new Usuario;
}
//Metodo de exemplo mas minha idéia e fazer algo semelhante ao "hibernate" na parte de gerenciamento
//dos dados via classes e getters e setters
public function carrega($id){
try {
$sql = 'SELECT ID_USUARIO,EMPRESA_ID,NOME FROM GUSUARIO WHERE ID_USUARIO = ?';
$result = $this->_Conexao->prepare($sql);
$result->bind_param('i', $id);
$result->execute();
//Não encontrei outro método mais simples para pegar os resultados
//e passar
$result->bind_result($idUsuario, $EmpresaID, $Nome);
$result->fetch();
$this->_Usuario->setIDUSUARIO($idUsuario);
$this->_Usuario->setEMPRESAID($EmpresaID);
$this->_Usuario->setNOME($Nome);
return $this->_Usuario;
$this->_Conexao->closeConnection();
}
catch (Exception $e) {
echo $e->getMessage();
}
}
public function salva(Usuario $usuario) {
}
public function listaTudo() {
//
}
public function atualiza(Usuario $usuario) {
}
public function remove(Usuario $usuario) {
}
}View[Página html]
require_once "biblioteca/funcoes/init.php";
$dao = new UsuarioDao();
$usuario = $dao->carrega(3);
echo $usuario->getNOME();
echo('<br/>');
echo $usuario->getIDUSUARIO();
echo('<br/>');
echo $usuario->getEMPRESAID();
echo('<br/>');Minha dúvida seria saber se estou no caminho certo, se meu método carrega está totalmente orientado a objeto
Agradeço a quem me ajudar
Olá amigo, muito obrigado pelas respostas e não está sendo chato não, está sendo verdadeiro e me tratando como um profissional isso é ótimo ;)
Certo, entendi todas suas indagações agora as respostas, rs.
>
Não se preocupe com organização de diretório, MVC não tem absolutamente nada a ver com isso, organize seus diretórios de uma forma semântica, que fique fácil para qualquer pessoa entender e conseguir manter a aplicação.
Quanto aos diretórios eu imaginava que era parte relacionada a mvc tbm, rs, venho do Java e é batido muitas e muitas vezes o que pode ter me trazido um pouco de confusão.
>
No caso de entidades, não há muito o que fazer, a não ser manter um padrão de escrita de código.
Por convenção, utiliza-se CamelCase para nomes de classes e camelCase para nomes de propriedades e métodos ou então Under_Score para classes e under_score para métodos e propriedades.
Ninguém gosta de ler código com propriedades e métodos capitalizados, é cansativo, principalmente em sistemas grandes.
Então de certa maneira os atributos da classe está assim!
#Atributos
private $IDUSUARIO = null;
private $EMPRESAID = null;
private $NOME = null;
private $USUARIO = null;
private $SENHA = null;
private $NOMEPERFILID = null;
private $REGEXC = null;
private $PERMISSAOTOTAL = null;O certo ficaria assim correto?
#Atributos
private $idUsuario = null;
private $empresaId= null;
private $nome= null;
private $usuario= null;
private $senha= null;
private $nomePerfilId= null;
private $regExc= null;
private $permissaoTotal= null;É verdade bem mais legivel! :D
>
Qual o objetivo de se ter uma propriedade $_Usuario para a instância do objeto ???
Veja, se você retorna um $_Usuario no método carrega() e não usa mais essa instância, não tem sentido carregar esse objeto no seu DAO. Nesse caso, prefira utilizar uma variável local em vez de uma propriedade do objeto.
Então achei que era necessário, mas entendi completamente a sua concepção, acaba utilizando memória atoa né.
>
Muito bom, apesar de Singleton não ser a pegada adequada para banco de dados, é um bom início.
Se singleton não é a pegada certa qual seria a melhor forma, eu utilizava muito hibernate e nhibernate e acabei tipo "viciando", tanto que meu objetivo é tentar fazer meus projetos trabalharem de certa forma parecido com o que eu fazia em outras linguagens.
>
Mas Singleton de que ?
Qual a interface que DB::getInstance() lhe retorna ?
E se amanhã, você precisar mudar a conexão de um banco X para um banco Y ou até mesmo, utilizar um sistema de armazenamento baseado em cloud, através de webservices ?
$sql = 'SELECT ID_USUARIO,EMPRESA_ID,NOME FROM GUSUARIO WHERE ID_USUARIO = ?';
$result = $this->_Conexao->prepare($sql);
$result->bind_param('i', $id);Desculpa mas esta parte não entendi ao certo
Esta seria a solução certa?
>
Em uma instrução simples, essa pegada é adequada, mas se você tiver uma consulta mais complexa, prefira utilizar parâmetros nomeados:
$stm = $this->_Conexao->prepare( 'SELECT ID_USUARIO,EMPRESA_ID,NOME FROM GUSUARIO WHERE ID_USUARIO=:id;' );
$stm->bind_param( ':id' , $id );>
Onde você encontrou essas variáveis $idUsuario, $EmpresaID, $Nome ???
Eu não consegui vê-las em lugar algum do código !!!
O fato do método bind_result aceitar seus parâmetros por referência, não exclui a necessidade de declará-los:
Entendi certamente, acabei acostumando com a facilidade do php, rsr
Eu imaginei se não tinha uma possibilidade mais rápida de dar um bind_result nos resultados, tentei até fazer usando os "set" diretamente mas não
obtive resultado.
>
>
View[Página html]
$dao = new UsuarioDao();
$usuario = $dao->carrega(3);Esse é o único ponto totalmente errado.
Não é responsabilidade da view "carregar" nada, seu controlador deve passar essa informação mastigada para ela.
Entendi, quanto ao controller eu não implementei por imaginar que a view seria o controller, se é que me entende, qual seria a melhor maneira de fazer um controller util para este momento?
Poderia me citar um exemplo?
>
Sim, está orientado a objetos sim, mas orientado à implementação e não à interfaces. Procure definir as interfaces dos seus objetos e trabalhe exclusivamente com elas.
Como a única forma de se saber o que um determinado objeto X faz é através de sua interface, a ausência delas é um grande erro.
Eu deixei para uma futura implementação mas estou já por dentro desta forma, estava pensando em colocar uma interface por cada tipo de classe
Exemplo
class Entidades implements IEntidades{}
class Dao implements IDao{}
class Controller implements IController{}
e por ai vai, se for isso que você mencionou é claro, rs
Agradeço e muito a todas as explanações concerteza aumentou mais o meu conhecimento :D
Ola amigo nao quero ser chato como amigo de cima hehehe
mais sim uma avaliador , em seu texto você passou a imagem de nao conhece muito a fundo O padrao MVC , repare que isso nao e critica
você nao acha mais pratico você pegar um framerwork como cake ou code igniter e trabalha com eles durante uma temporada
para que o padrao MVC faça parte de você
Por exemplo conheco excelente programadores em java script que olha o jquery como um modelo de inspiração
com o aprendizado no jquery fizeram coisas maneras em js com ou sem jquery
por exemplo:
HMVC é uma evolução do padrão MVC utilizado para a maioria das aplicações web hoje em dia.
Baixe e instale CodeIgniter com HMVC :)
>
Quanto aos diretórios eu imaginava que era parte relacionada a mvc tbm, rs, venho do Java e é batido muitas e muitas vezes o que pode ter me trazido um pouco de confusão.
Mesmo no Java, a organização de diretórios tem um objetivo semântico, não importa se é MVC ou não, a organização deve ser feita de uma forma que qualquer pessoa compreenda o que está acontecendo e possa manter o código facilmente.
>
É verdade bem mais legivel!
:D
>
Então achei que era necessário, mas entendi completamente a sua concepção, acaba utilizando memória atoa né.
De forma geral, apesar do garbage collector do PHP fazer o trabalho de limpar o "lixo" para você, não tem sentido ficar acumulando lixo só porque esse trabalho será feito.
Mantenha seu código limpo, declare propriedades apenas para o que você realmente precisa, trabalhe com variáveis locais quando um determinado valor estiver relacionado apenas ao retorno de um método. Evite criar propriedades para tudo, prefira passar um determinado valor para um método.
Por exemplo:
class Example {
private $connection;
public function __construct(){
$this->connection = DB::getInstante();
}
public function save(){
$this->connection->doSomething()
}
}
$example = new Example();
$example->save();
Durante todo o ciclo de vida desse objeto ele carregará uma instância de um objeto de conexão. Isso é realmente necessário ???
Imagine o seguinte:class Example {
public function save( DB $connection ){
$connection->doSomething();
}
}
$example = new Example();
$example->save( DB::getInstance() );
Como você pode perceber, seu código fará a mesma coisa, mas será mais fácil mantê-lo, ele está menor e você não está carregando uma instância inútil.
Vamos supor que amanhã você precise trabalhar com um outro sistema de armazenamento:
Como você faz referência explícita ao seu DB::getInstance() dentro do seu construtor, você terá dois caminhos:
1. Editar o arquivo Example e mudar de DB::getInstante() para OutroDB::getInstance()
OU
2. Editar o arquivo DB para mudar a instância do objeto de conexão.
Imagine agora que DB é uma interface.interface DB {
public function doSomething();
}class SomeStorageEngine implements DB {
public function doSomething(){
//...
}
}class OtherStorageEngine implements DB {
public function doSomething(){
//...
}
}
Usando no mesmo Example:
$storage = new SomeStorageEngine();
$example = new Example();
$example->save( $storage );
Ou
$storage = new OtherStorageEngine();
$example = new Example();
$example->save( $storage );
Como fica fácil perceber, essa mudança fez com que sua aplicação se torne facilmente escalável, você não precisará editar código para adequar à uma nova realidade.>
Se singleton não é a pegada certa qual seria a melhor forma, eu utilizava muito hibernate e nhibernate e acabei tipo "viciando", tanto que meu objetivo é tentar fazer meus projetos trabalharem de certa forma parecido com o que eu fazia em outras linguagens.
Singleton, como o nome diz, refere-se à uma instância única de um objeto qualquer. Muitas vezes, só nos damos conta do problema, quando deparamos com ele, imagina que hoje você tenha apenas um sistema de armazenamento, então Singleton é totalmente adequado.
Mas imagina que amanhã sua aplicação cresça e que você precise trabalhar com 2 sistemas de armazenamento distintos, ao mesmo tempo, na mesma aplicação.
Como você faria nessa situação ??
Por exemplo:
$user = new User();
$order = new UserOrder( $user );
Imagine que você tenha os dados de um novo usuário e um pedido de compra desse usuário. Imagine que você tenha que gravar os dados do usuário no seu banco local e o pedido de compra em um sistema de armazenamento externo.
Como você lidaria com um Singleton ? Teria um Doubleton ?????
É fato que você precisa ter uma única instância de um objeto de conexão para uma conexão X, se você tiver que trabalhar com 2 sistemas de armazenamento, você terá que ter 2 instâncias, únicas, uma para cada sistema de armazenamento.
Se amanhã você tiver N sistemas de armazenamento, que trabalharão juntos, ao mesmo tempo, na mesma aplicação, você deverá ter N instâncias únicas, uma para cada sistema de armazenamento.
Como lidar com isso ?
:seta: Singleton Registry.
Para você que já está acostumado com Java, Registry é um Map<String,DB> onde a String é uma chave que identifica sua conexão e DB é uma instância de um objeto qualquer que implementa a interface DB.
Em Java, seria assim:
package com.example.data;public interface Data {
}
package com.example.data;
public class User implements Data {
}
package com.example.data;
public class UserOrder implements Data {
}
package com.example.storage;
import com.example.data.Data;public class AWSS3 implements DB {
@Override
public void doSomething( Data data ) {
System.out.println( "Amazon Web Services S3" );
}
}
package com.example.storage;
import com.example.data.Data;public interface DB {
public void doSomething( Data data );
}
package com.example.storage;
import com.example.data.Data;public class MySQLStorage implements DB {
@Override
public void doSomething( Data data ) {
System.out.println( "MySQLStorage" );
}
}
package com.example.util;
import java.util.HashMap;
import java.util.Map;
import com.example.storage.DB;public class Registry {
private static Registry instance;
public static Registry getInstance() {
if ( instance == null ) {
instance = new Registry();
}
return instance;
}
private final Map<String , DB> storage;
private Registry(){
storage = new HashMap<String , DB>();
}
public void clear() {
storage.clear();
}
public boolean containsKey( Object key ) {
return storage.containsKey( key );
}
public DB get( Object key ) {
return storage.get( key );
}
public DB put( String key , DB value ) throws Throwable {
if ( !containsKey( key ) ){
return storage.put( key , value );
} else {
throw new UnsupportedOperationException( "Já existe um valor para essa chave" );
}
}
}
package com.example;
import com.example.data.User;
import com.example.data.UserOrder;
import com.example.storage.AWSS3;
import com.example.storage.MySQLStorage;
import com.example.util.Registry;public class Example {
public static void main( String[] args ) {
final Registry registry = Registry.getInstance();
try {
registry.put( "aws" , new AWSS3() );
registry.put( "mysql" , new MySQLStorage() );
final UserDAO dao = new UserDAO();
dao.save( new User() , new UserOrder() );
} catch ( final Throwable e ) {
e.printStackTrace();
}
}
}
package com.example;
import com.example.data.User;
import com.example.data.UserOrder;
import com.example.util.Registry;public class UserDAO {
public void save( User user , UserOrder order ) {
Registry.getInstance().get( "mysql" ).doSomething( user );
Registry.getInstance().get( "aws" ).doSomething( order );
}
}
Para implementar no PHP você pode utilizar a [SplObjectStorage](http://php.net/manual/en/class.splobjectstorage.php) e obter o mesmo resultado.>
Entendi certamente, acabei acostumando com a facilidade do php, rsr
Durando o desenvolvimento, procure adicionar as duas linhas abaixo, logo no início do seu código:
<?php
ini_set( 'display_errors' , 'On' );
error_reporting( E_ALL | E_STRICT );// restante do código
>
Eu imaginei se não tinha uma possibilidade mais rápida de dar um bind_result nos resultados, tentei até fazer usando os "set" diretamente mas não
obtive resultado.
Usando a PDO você consegue evitar todos os "set" através do setFetchMode()
<?php
$pdo = new PDO(...);
$stm = $pdo->prepare( ... );
$stm->setFetchMode( PDO::FETCH_CLASS , 'User' );
$stm->execute();foreach ( $stm->fetchAll() as $user ){
//$user é uma instância de User com suas propriedades já populadas.
}
>
Entendi, quanto ao controller eu não implementei por imaginar que a view seria o controller, se é que me entende, qual seria a melhor maneira de fazer um controller util para este momento?
Poderia me citar um exemplo?
Vamos deixar esse exemplo para um próximo post, esse já ficou muito grande. :P
>
Eu deixei para uma futura implementação mas estou já por dentro desta forma, estava pensando em colocar uma interface por cada tipo de classe
A interface de um objeto é a primeira, não a última coisa a se fazer.
Se você criar as interfaces por último, você terá ainda um código orientado a implementação. Modele sua aplicação primeiro, somente depois comece a codificar.
Isso evitará muitos problemas no futuro.
>
Ola amigo nao quero ser chato como amigo de cima hehehe
:P
>
você nao acha mais pratico você pegar um framerwork como cake ou code igniter e trabalha com eles durante uma temporada
para que o padrao MVC faça parte de você
Por exemplo conheco excelente programadores em java script que olha o jquery como um modelo de inspiração
com o aprendizado no jquery fizeram coisas maneras em js com ou sem jquery.
Baixe e instale CodeIgniter com HMVC
Utilizar um framework como inspiração é uma "boa pegada", mas para que isso seja proveitoso, é necessário conhecer o conceito antes, de que adianta trabalhar com um MVC hierárquico, se você sequer compreendeu o motivo de se existir MVC ?
Li e analisei o código do Codeigniter e posso afirmar, com convicção que é pseudo orientado a objetos, mal organizado e, sinceramente, que é um código feio.
Já o Zend Framework é um código mais organizado, com uma boa delegação e um bom uso de padrões de projeto e arquitetura, mas é gigante, muito além das necessidades da grande maioria das aplicações web.
Mas, independentemente de um ou de outro, não passam de ferramentas. Não basta dar um serrote à uma pessoa que você fará dessa um carpinteiro.
;)
>
Mesmo no Java, a organização de diretórios tem um objetivo semântico, não importa se é MVC ou não, a organização deve ser feita de uma forma que qualquer pessoa compreenda o que está acontecendo e possa manter o código facilmente.
Entendi perfeitamente :D
>
De forma geral, apesar do garbage collector do PHP fazer o trabalho de limpar o "lixo" para você, não tem sentido ficar acumulando lixo só porque esse trabalho será feito.
Mantenha seu código limpo, declare propriedades apenas para o que você realmente precisa, trabalhe com variáveis locais quando um determinado valor estiver relacionado apenas ao retorno de um método. Evite criar propriedades para tudo, prefira passar um determinado valor para um método.
Durante todo o ciclo de vida desse objeto ele carregará uma instância de um objeto de conexão. Isso é realmente necessário ???
Imagine o seguinte:
class Example {
public function save( DB $connection ){
$connection->doSomething();
}
}
$example = new Example();
$example->save( DB::getInstance() );Gostei da explanação entendi perfeitamente a utilidade do mesmo a parte de passar a conexao no construtor.
>
Imagine que você tenha os dados de um novo usuário e um pedido de compra desse usuário. Imagine que você tenha que gravar os dados do usuário no seu banco local e o pedido de compra em um sistema de armazenamento externo.
Como você lidaria com um Singleton ? Teria um Doubleton ?????
Eu ri disso :D rsr
Então nesse caso eu acho que seria mais facil só alterar o caminho da conexão não? só se mudasse o tipo de conexão, rs, a parte da conexão imagino q ficou bem claro pra mim, tbm se é singletown não há a necessidade de deixa-la fixa no construtor né, já q ela pode pegar a mesma instancia varias vezes posso usa-la local mesmo.
>
Para implementar no PHP você pode utilizar a SplObjectStorage e obter o mesmo resultado.
Irei estudar sobre o assunto
Durando o desenvolvimento, procure adicionar as duas linhas abaixo, logo no início do seu código:
>
<?php
ini_set( 'display_errors' , 'on' );
error_reporting( E_ALL | E_STRICT );// restante do código
Ai que tá, rs, eu habilito geralmente os erros mas desabilitos os NOTICES E WARNING, foi isso então.
>
>
Eu imaginei se não tinha uma possibilidade mais rápida de dar um bind_result nos resultados, tentei até fazer usando os "set" diretamente mas não
obtive resultado.
Usando a PDO você consegue evitar todos os "set" através do setFetchMode()
<?php
$pdo = new PDO(...);
$stm = $pdo->prepare( ... );
$stm->setFetchMode( PDO::FETCH_CLASS , 'User' );
$stm->execute();foreach ( $stm->fetchAll() as $user ){
//$user é uma instância de User com suas propriedades já populadas.
}
Aparentemente então com mysqli a unica forma é usando bind_result né, rs, vou pesquisar mais sobre.
>
Entendi, quanto ao controller eu não implementei por imaginar que a view seria o controller, se é que me entende, qual seria a melhor maneira de fazer um controller util para este momento?
Poderia me citar um exemplo?
Vamos deixar esse exemplo para um próximo post, esse já ficou muito grande. :P
>
Eu deixei para uma futura implementação mas estou já por dentro desta forma, estava pensando em colocar uma interface por cada tipo de classe
Estarei aguardando. rs
>
>
Ola amigo nao quero ser chato como amigo de cima hehehe
:P
>
você nao acha mais pratico você pegar um framerwork como cake ou code igniter e trabalha com eles durante uma temporada
para que o padrao MVC faça parte de você
Por exemplo conheco excelente programadores em java script que olha o jquery como um modelo de inspiração
com o aprendizado no jquery fizeram coisas maneras em js com ou sem jquery.
Baixe e instale CodeIgniter com HMVC
Utilizar um framework como inspiração é uma "boa pegada", mas para que isso seja proveitoso, é necessário conhecer o conceito antes, de que adianta trabalhar com um MVC hierárquico, se você sequer compreendeu o motivo de se existir MVC ?
É nessa parte eu concordo com ambos, rs, a parte de aprender usando um framework é interessante eu tenho certas experiencias usando frameworks mas não em php, sim, com jquery(js) e vraptor(java), mas preferia na tentativa e erro entende, assim imagino q aprendo mais, para não criar certos vicios de frameworks, mas muito obrigado pelas implementações, estarei modificando meu código e postarei novamente para ver se consegui atingir meu objetivo,
Obrigado e acho que servirá para muitos outros esse tópico, pois muitos nem sabem ao certo como implementar essa parte já que a maioria do material encontrado é usando frameworks, não achei nenhum material mostrando qual a melhor forma de implementação e sim como tem que ser, rs..
Obrigado a todos pela explanação e pode ter certeza q aumentou em muito meu conhecimento
@João Batista nao sabia que era tu que estava ai em cima hehehe
ainda te chamei de chato heheheheh ,desculpe :)
Mais minha ideia e so como referência , tira o que eles tem de bom mesmo,afinal nada e 100%
acredito que sua ideia ja serviu como um norte para ele
Porque eu tenho desejo de montar uma ferramenta propria no futuro
mais aprendi muita coisa manera nos framerwork generico :)
um abraço meu velho fui
>
@João Batista nao sabia que era tu que estava ai em cima hehehe
ainda te chamei de chato heheheheh ,desculpe
heheheh, não se preocupe amigo, eu mesmo me chamei de chato logo no início. ;)
De fato, eu acredito veementemente que a sinceridade é a melhor forma de ajudar alguém a crescer.
Quando eu comecei com programação, aos 14 anos de idade, todos viam meu código e diziam: "Nossa, que bonitinho, o garoto sabe programar"
Sabe, por conta disso, levei muito tempo para tomar conhecimento de que eu não sabia nada, até que um dia, um cara virou para mim e disse: "Vou ser sincero com você, seu código é um lixo".
Claro que na hora eu pensei: "Esse cara é um chato".
Mas foi justamente por conta da "chatice" desse cara (um analista de software) que eu realmente comecei a estudar a fundo e o faço até hoje.
Comunidades como o fórum iMasters reúnem os mais diversos desenvolvedores, com os mais diversos problemas e isso é definitivamente a maior fonte de inspiração que alguém pode ter, são problemas reais, enfrentados por pessoas reais, para clientes reais.
Livros são ótimos, tenho uma biblioteca invejável, mas nem todos os livros juntos possuem nem 10% do conhecimento agregado que existe em um fórum como esse, estudar os problemas das pessoas reais levam a soluções práticas e baratas.
>
Mais minha ideia e so como referência , tira o que eles tem de bom mesmo,afinal nada e 100%
Sim, exatamente por isso que concordei com você, quando você falou sobre utilizar um framework como fonte de inspiração, principalmente o CI que conta com uma comunidade tão grande.
O único problema do CI é que a Ellis Labs "amarra" o desenvolvimento dele por conta de suporte legado, por isso ele é "feio" e por isso que muitos desenvolvedores deixaram de colaborar com seu desenvolvimento e passaram a desenvolver o Kohana.
>
Porque eu tenho desejo de montar uma ferramenta propria no futuro
mais aprendi muita coisa manera nos framerwork generico
Eu segui esse mesmo caminho, desenvolvi dois pacotes de desenvolvimento de objetos reutilizáveis, utilizando o know-how adquirido no estudo do Java.
Com a RPO e a DSO é possível resolver problemas dos mais simples aos mais complexos com pouquíssimo esforço, mas também é necessário ter um conhecimento profundo em orientação a objetos. O nível de delegação, abstração e desacoplamento dos dois pacotes fizeram com que o uso deles ficasse um tanto complexo para quem não conhece bem OOP e, justamente por isso, ainda não os tornei de domínio público.
:seta: Vou deixar um quote de Albert Einstein que eu gosto muito:
>
Não basta ensinar ao homem uma especialidade. Porque se tornará assim uma máquina utilizável, mas não uma personalidade. É necessário que adquira um sentimento, um senso prático daquilo que vale a pena ser empreendido, daquilo que é belo, do que é moralmente correto ...
Os excessos do sistema de competição e de especialização prematura, sob o falacioso pretexto de eficácia, assassinam o espírito, impossibilitam qualquer vida cultural e chegam a suprimir os progressos nas ciências do futuro ... O ensino deveria ser assim: quem o receber o recolha como um dom inestimável, mas nunca como uma obrigação penosa".
;)
@joao com certeza , a sinceridade e a base de tudo
essa parte do seu texto aqui e a mais pura verdade
>
Comunidades como o fórum iMasters reúnem os mais diversos desenvolvedores, com os mais diversos problemas e isso é definitivamente a maior fonte de inspiração que alguém pode ter, são problemas reais, enfrentados por pessoas reais, para clientes reais.
Livros são ótimos, tenho uma biblioteca invejável, mas nem todos os livros juntos possuem nem 10% do conhecimento agregado que existe em um fórum como esse, estudar os problemas das pessoas reais levam a soluções práticas e baratas.
eu estou sempre buscando aprende , e o legal que aqui no forum temos chance de conhece excelente POG.
eu pretendo montar o meu so quando eu tive 10 anos de experiencia ainda faltar 4 anos ainda :(
venho trabalhando , vem estudando , hj em dia eu estudo mais e padrao de programação.
vendo coisa no "pear"
Espero que o autor da postagem tenha sensibilidade e humildade para entende suas ideias.
Ter filho como nosso nome exigi boas praticas de programação :)
>
Espero que o autor da postagem tenha sensibilidade e humildade para entende suas ideias.
Ter filho como nosso nome exigi boas praticas de programação :)
Opa certeza, todas as dicas foram de alto teor de ajuda, estarei refazendo a mesma, para repassar para os senhores, mas tenha certeza que o conhecimento é algo que não pode ser tirado de nós :D
João Batista, boa noite?!
Eu li sua otima explicação para o colega acima. Parabéns, otima didática.
João, estou começando em PHP com Netbeans. Haveria a possibilidade de você me enviar um pequeno sistema de login seguro contemplando os seguintes itens:
-
Isso já será um ótimo começo pra mim. Meu e-mail é webnetbrasil@hotmail.com
Forte abraço e fique com Deus
@kivervinicus, outro detalhe simples,
A nomenclatura está em português.
Padronize para inglês.
kivervinicius,
Devo dizer que você está no caminho correto, sua estrutura é boa, mas ainda tem alguns probleminhas.
Vou ser extremamente chato, pois é notório que seu nível já está um pouco além e você conseguirá "captar" a ideia melhor:
>
/applications/core/interface/imageproxy/imageproxy.php?img=http://img703.imageshack.us/img703/9374/pastas.jpg&key=5511c7332feb55486198f94b00108036fc26dc3e945d2cac3728702a9311d79b" alt="pastas.jpg">
Não se preocupe com organização de diretório, MVC não tem absolutamente nada a ver com isso, organize seus diretórios de uma forma semântica, que fique fácil para qualquer pessoa entender e conseguir manter a aplicação.
>
Vou postar alguns códigos de exemplos de como na minha concepção deveria ser
Classe Bean[ENTIDADES]
No caso de entidades, não há muito o que fazer, a não ser manter um padrão de escrita de código.
Por convenção, utiliza-se CamelCase para nomes de classes e camelCase para nomes de propriedades e métodos ou então Under_Score para classes e under_score para métodos e propriedades.
Ninguém gosta de ler código com propriedades e métodos capitalizados, é cansativo, principalmente em sistemas grandes.
>
Classe DAO[UsuarioDao]
class UsuarioDao {
Qual o objetivo de se ter uma propriedade $_Usuario para a instância do objeto ???
Veja, se você retorna um $_Usuario no método carrega() e não usa mais essa instância, não tem sentido carregar esse objeto no seu DAO. Nesse caso, prefira utilizar uma variável local em vez de uma propriedade do objeto.
>
Muito bom, apesar de Singleton não ser a pegada adequada para banco de dados, é um bom início.
Mas Singleton de que ?
Qual a interface que DB::getInstance() lhe retorna ?
E se amanhã, você precisar mudar a conexão de um banco X para um banco Y ou até mesmo, utilizar um sistema de armazenamento baseado em cloud, através de webservices ?
>
Em uma instrução simples, essa pegada é adequada, mas se você tiver uma consulta mais complexa, prefira utilizar parâmetros nomeados:
>
$result->bind_result($idUsuario, $EmpresaID, $Nome);
Onde você encontrou essas variáveis $idUsuario, $EmpresaID, $Nome ???
Eu não consegui vê-las em lugar algum do código !!!
O fato do método bind_result aceitar seus parâmetros por referência, não exclui a necessidade de declará-los:
//agora sim
>
Veja o problema.
Seu método carrega, por usar uma instância de Usuario como propriedade do objeto, carregará esse objeto por todo seu ciclo de vida, ou seja:
O correto seria:
//...
>
View[Página html]
Esse é o único ponto totalmente errado.
Não é responsabilidade da view "carregar" nada, seu controlador deve passar essa informação mastigada para ela.
>
Minha dúvida seria saber se estou no caminho certo, se meu método carrega está totalmente orientado a objeto
Sim, está orientado a objetos sim, mas orientado à implementação e não à interfaces. Procure definir as interfaces dos seus objetos e trabalhe exclusivamente com elas.
Como a única forma de se saber o que um determinado objeto X faz é através de sua interface, a ausência delas é um grande erro.
No mais, como disse logo no início, você está no caminho correto.
;)