CRUD Orientado a Objetos

[bidoofreak 0]

Oi gente!

 

Me foi passado um desafio pra fazer um CRUD neste modelo, orientado a objetos:

 

 

Também me foram passadas algumas instruções sobre modelo de classes e modelagem de banco de dados:

 

 

 

Na realidade, fiz a modelagem do banco:

 

 

Eu precisava, portanto, que alguém me ajudasse a entender como seria a estrutura desse CRUD.

 

1. Preciso pensar em Model <- Controller <- -> View -> Model? Gostaria de entender BEM o que seria essa estrutura, mas com uma explicação que se referenciasse a este projeto.

 

2. Queria saber como deverá ser a estruturação das pastas do meu projeto.

 

3. E também gostaria de saber quais as classes que devo criar pra isso tudo.

 

4. E outra coisa, também não entendi se esse CRUD vai ser acessado somente por um usuário administrador, ou se ele deve ter níveis de acesso.

 

Valeu gente!

[visitante_php 0]

se nao sabe o q eu ou como fazer, nao faça, mas...a diagramacao de classe esta errada, nao eh funcao da classe funcionario, checar a senha do mesmo , e sim responsabilidade de uma classe de autenticacao...

 

1. Preciso pensar em Model <- Controller <- -> View -> Model? Gostaria de entender BEM o que seria essa estrutura, mas com uma explicação que se referenciasse a este projeto.

 

isto nao eh estrutura e sim arquitetura de software, existe na verdade isso model <=> controller <=> view, onde o model trabalha com os dados no banco de dados, o view apenas os apresenta ao ususario e entra com dados enviados pelo usuario, e o controler eh que faz o processamento, decide o q faz com os dados obtidos no banco e enviados pela view...

 

2. Queria saber como deverá ser a estruturação das pastas do meu projeto.

 

existem diversas, o zend framework por exemplo, baseia-se em hierarquia de importancia e assunto...

 

3. E também gostaria de saber quais as classes que devo criar pra isso tudo.

 

você deveria primeiro estudar orientacao a objetos, o correto, pq tem muita gente q faz classes e faz gambiarras usando classes....classe eh apenas um nivel basico de orientacao a objetos...

 

4. E outra coisa, também não entendi se esse CRUD vai ser acessado somente por um usuário administrador, ou se ele deve ter níveis de acesso.

 

se você esta o programando deveria saber, nos tb nao sabemos, mas você tb deveria perguntar a kem mandou criar ou reparar....

[Evandro Oliveira 331]

Partindo do ponto que seu banco de dados já está modelado e não haverá alteração de tabelas, já podemos tirar duas conclusões:

 

1 - Não haverá níveis de acesso, uma vez que não existe uma tabela Usuário/Nível

2 - Não existe CRUD no seu sistema. CRUD se aplica a nível tabelas<->dados, e você vai manipular apenas os dados, não existe nem o Create nem o Delete.

 

O João ja te ensinou como linkar e implementar as classes referenciais dentro de uma classe mestra. Tá quase tudo pronto lá.

 

Creio eu que, os setters não estejam lá pelo simples capricho de estar, logo, cada vez que você fizer uma chamada a nível setVar($value), creio que essa função já deverá aplicar um 'UPDATE `table` SET...' no BD, além da funcionalidade óbvia de alterar o valor da variável local.

 

 

eu trabalharia da seguinte forma:

uma classe estática para manipulação do BD para fazermos uso das técnicas de DRY

 

mysql::new(string $object, mixed $properties) que fará a chamada 'INSERT INTO `table` VALUES ...', e instanciará um novo objeto da classe passada via $object, ou será colocada dentro dos construtores de cada classe, instanciando em $properties, os valores passados na construção do objeto (recomendo a segunda)

 

mysql::del(stdClass $object) aqui você pode ler o tipo de objeto para descobrir o quê ele é, e utilizar um getId() para passar o 'DELETE FROM'. Das duas uma, ou você coloca este método dentro dos destrutores de classe, ou você faz o método destruir a classe passada (recomendo a segunda)

 

mysql::edit(stdClass $object, string $field) descobre o tipo de objeto analogamente à ::del() e passa o 'UPDATE `` SET ``...'. Este método deve ser chamado DENTRO dos setters impreterívelmente

 

se o banco estiver bem modelado e estruturado, as foreign keys se encarregarão do cascateamento

 

 

 

PS.: Isso não é trabalho de facul não né? é feio pedir ajuda pra isso :P

[bidoofreak 0]

Olha Evandro, não é trabalho da faculdade não. Mas feio é não fazer, ou fazer mal feito por orgulho e vergonha de perguntar e esclarecer as dúvidas.

 

Respostas como a do Igor, por exemplo, não me ajudam em nada. Já estou esgotado de arrogância em respostas. É evidente que preciso aprender, e é por isso que busco a ajuda de vocês, porque considero todos aqui como profissionais de muito valor.

 

Com relação ao CRUD, não entendi porque falaste que ele não terá Delete nem Cadastro. Poderia explicar melhor?

 

E outra coisa, a criação das classes Cliente, Funcionario e OrdemDeServico já dão conta de todo o sistema, juntamente com a classe Banco, criada pra a manipulação destes dados, correto?

[visitante_php 0]

peço entao desculpas, agora seria bom estudo de design patterns, pq muitos falam em orientacao a objetos e nem pesquisam o q eh orientacao a objetos, acham q td eh classe, at criam classe pra banco de dados, exstem tantas classes de conecoes a banco de dados nativas do prorpio php, mas o pessoal tem preguiça de pesquisar no manual, preferem perder tempo e criar uma nova com menos de 1% do q as nativas fazem....la tem at mesmo uma secao de design patterns.....como nao podemos colocar scripts prontos, e sim indicar a solucao... vou t dar umas dicas de design patterns, procure os padroes singleton, registry, active record, collection record, single table, lembre-se cada objeto possui responsabilidades sobre seus atos, ou seja,, atributos e metodos.....procure pbservar o zend framework, cada classe eh especializada numa coisa.....exemplo a citar, uma classe pra conectar e desconectar, e outra pra operar no banco....

 

uma coisa, o hinom iniciou uma serie de orientacao a objetos com mvc aki no forum, vale muito a pena conferir....

[bidoofreak 0]

Igor.php

 

Beleza Igor, sem problemas.

 

Agora com relação ao estudo disso tudo, estou lendo o livro PHP - Programando com Orientação a Objetos, do Pablo Dall'Oglio. É muito bom, porque explica bem como funciona essa parte de design patterns.

 

Mas eu precisava de uma exemplificação de como seria a estrutura, entende? Da maneira mais simples possível.

 

Por exemplo:

 

-- www/

---- app/

-------- app.controll

-------- app.model

------------ model.cliente/

---------------- CRUD

------------ model.funcionario/

---------------- CRUD

------------ model.ordemdeservico/

---------------- CRUD

-------- app.view

---- index.php

 

Não sei se estou planejando corretamente, preciso de uma exemplificação dessa maneira. Entendendo a estrutura das pastas, fica mais simples entender o que cada classe fará dentro de cada estrutura.

 

Estou certo?

[visitante_php 0]

bom...pelo q estou vendo você nao sabe o q eh crud, crud eh na verdade Create(antigo insert), Read(antigo select), Update, Delete, as 4 operacoes basicas num banco de dados, esse livro q você esta lendo eh excelente, eu ia at recomenda-lo, porem eu tinha perdido o link, eu ja o li, eu inclusive criei meu proprio framework baseado nele, claro, usando um codigo diferente pra evitar plagio...antes de definir a estrutura de diretorio você precisa entender a arquitetura mvc,

 

model-> prove operacoes num banco de dados

 

view-> envia os dados do controller ao usuario

 

controller-> processa os dados, fas as operacoes....

 

o controller usa o model pra resgatar os dados do banco, e envia-los pra la, e usa a view pra mostrar os dados ao ususario, e receber dados do usuario,

 

o q o controller faz com os dados enviados para o usuario? ele os processa, soma, subtrai, envia por email, depende de como você vai programa-los.....outr acoisa,

 

qual sera a nomenclatura de suas classes? isso tb define uma hierarquia de pastas....o zend framework tb baseia-se em quando mais especializada a classe mais um nivel hierarquico ele eh.... exemplo

 

uma classe q prove autenticacao

 

eu tenho o zend->core->database->autenticacao

 

zend_core_database_autenticacao, somente a ultima palavra eh uma classe, as 3 anteriores sao pastas, nas quais estao classes q vao se especializando....

 

 

você pode fazer tb assim

 

App/model/class.php

App/view/class.php

App/controller/class.php

 

e no autoload chamar assim

function __autoload($class)
{
if(file_exists("App/model/{$class}.php"))
{
require_once("App/model/{$class}.php");
}
else if(file_exists("App/view/{$class}.php"))
{
require_once("App/view/{$class}.php");
}
elseif(file_exists("App/controller/{$class}.php"))
{
require_once("App/controller/{$class}.php");
}
else
{
throw new Exception("class not fount: {$class}.php");
}
}

//e chama assim

$class = new Model();

 

 

lembrando isso eh muito relativo, eu faço por hierarquia, mas depende muito....

[bidoofreak 0]

Sim Igor, entendi a questão do CRUD. Veja só o que planejei para a estrutura da aplicação:

 

 

Mas estou pensando em uma coisa. Talvez a presença das instruções SQL dentro de uma pasta chamada (de acordo com o modelo do livro) app.ado seja redundante, afinal estas instruções estarão todas no model de cada parte (funcionario, cliente, ordem de servico).

 

Ou então, na verdade, o app.ado, onde ficam as instruções, terá as instruções básicas 'cruas', e cada CRUD de cada parte da aplicação chamará essas instruções e as implementará de maneira particular.

 

Como está a estrutura a seu ver?

[Evandro Oliveira 331]

vacilei no CRUD, confundi com outro conceito onde R = Remove (tabela) sendo que o R aqui seria Read

 

aqui eu organizo por extensão/funcionalidade mas porque o sistema não possui um painel de opções, então as alterações são todas feitas nos arquivos /cfg/arquivo.cfg, que são escritos em formato INI_Like e podem ser transportados para outras linguagens como aplicações em C

 

acredito que criar uma classe para cada ação no BD seja dispensável. Fica mais fácil pra você se orientar na estrutura, mas na codificação final, vai te trazer um absurdo de 'includes' em loop ou cascata.

 

se você estiver trabalhando em equipe, defina um padrão que seja aceitável para todos. Se estiver trabalhando sozinho, organize por funcionalidade

 

e a parte de 'As classes já dão conta de todo o sistema?', a resposta é para o que foi apresentado até agora, sim.

 

Ps.: o negócio de é feio pedir ajuda foi uma brincadeira