MVC

MESTRE 21/09/2017 10:00:48
#476688
Fala galera beleza? estou desenvolvendo em PHP MVC,

pedi que meu professor da faculdade desse uma olhada no projeto se estou seguindo o caminho correto, o mesmo achou muito bacana o projeto e disse estar bem encaminhado
e organizado que única coisa que alteraria seria utilizar BO[ô]s (Business Objects).. o projeto está separado em (Entidades, DAO, Controller, Views)..

O problema é que não achei quase material nenhum falando sobre BO[ô]s no PHP, em Java existem diversos padrões e materiais..

Meu projeto segue SOLID SRP (Single Responsability Principle)

realmente é necessario um BO?
JABA 21/09/2017 14:00:01
#476697
Quando se separa as características dos comportamentos para uma mesma entidade, pode-se chamar isso de qualquer coisa, menos de Orientação a Objetos. Tanto Java e .Net estão infestados de práticas que aderem a esse princípio. Se você não tiver um bom orientador, certamente vai cair nessa achando que está no caminho certo.
MESTRE 21/09/2017 15:25:13
#476702
Citação:

:
Quando se separa as características dos comportamentos para uma mesma entidade, pode-se chamar isso de qualquer coisa, menos de Orientação a Objetos. Tanto Java e .Net estão infestados de práticas que aderem a esse princípio. Se você não tiver um bom orientador, certamente vai cair nessa achando que está no caminho certo.



Então o ideal seria continuar sem o BO ??
KERPLUNK 21/09/2017 16:02:04
#476703
Tem certeza que você não está se referindo a BI?
JABA 21/09/2017 16:03:22
#476704
Citação:

Então o ideal seria continuar sem o BO ??



Se você entende isso como uma camada de aplicação, onde é utilizado apenas para fazer uso do seu de modelo de negócio, então, sim, você pode utilizar. O problema é quando começa a usar coisas como VO e DTO para transferir dados de uma camada lógica para outra.
MESTRE 21/09/2017 16:18:46
#476709
Citação:

:
Tem certeza que você não está se referindo a BI?


Não kerp ..

Citação:

:
Então o ideal seria continuar sem o BO ??

Se você entende isso como uma camada de aplicação, onde é utilizado apenas para fazer uso do seu de modelo de negócio, então, sim, você pode utilizar. O problema é quando começa a usar coisas como VO e DTO para transferir dados de uma camada lógica para outra.


Então na faculdade utilizamos e é cobrado.. o professor tem bastante experiência tanto na parte acadêmica como na profissional também, ele disse que a estrutura estava muito boa porém
faltava os BO[ô]s.. na meu projeto so tenho Entidades, View, DAO, Controllers.

Data Transfer Object – DTO ou TO Transfer Object
Um objeto simples usado para transferir dados de um local a outro na aplicação, sem lógica de negócios em seus objetos e comumente associado à transferência de dados entre uma camada de visão (view layer) e outra de persistência dos dados (model layer). Muito frequentemente você verá esse padrão sendo usado em conjunto com um DAO.


Business Object – BO
Um objeto de negócios é um tipo de uma entidade inteligível sendo e agindo como um ator dentro da camada de negócio em uma arquitetura de n camadas orientado a objeto.

Basicamente sua função é encapsular a lógica de negócios para um objeto (que pode incluir vários POs e geralmente precisam de um BO em um PO). Um PO pode ser um BO no final das contas, mas antes precisa ser convertido para tal.

Há três conceitos principais sobre BO:

Contém apenas as propriedades do objeto de negócio;
Contém apenas os métodos de negócio;
Ambos.
Durante o uso efetivo, o conceito do que é correto não é importante, a chave é apropriada para a aplicação prática em suas próprias necessidades de projeto.

ref: link aqui
JABA 21/09/2017 16:40:01
#476710
Os DTOs não foram criados para transferir dados de uma camada lógica para outra, isso aí é conhecido como um anti-padrão. Pegaram um conceito que é utilizado para aplicações distribuídas e transpuseram-o para as camadas lógicas. Veja o que Martin Fowler diz sobre essas coisas:

martinfowler.com/bliki/AnemicDomainModel.html
LLAIA 21/09/2017 16:48:14
#476712
Citação:

:
:
Quando se separa as características dos comportamentos para uma mesma entidade, pode-se chamar isso de qualquer coisa, menos de Orientação a Objetos. Tanto Java e .Net estão infestados de práticas que aderem a esse princípio. Se você não tiver um bom orientador, certamente vai cair nessa achando que está no caminho certo.

Então o ideal seria continuar sem o BO ??




Cara estuda sobre classes anêmicas e veja o porquê não é indicado. Arquitetura BOLOVO.
MESTRE 21/09/2017 17:02:52
#476713
Citação:

:
Os DTOs não foram criados para transferir dados de uma camada lógica para outra, isso aí é conhecido como um anti-padrão. Pegaram um conceito que é utilizado para aplicações distribuídas e transpuseram-o para as camadas lógicas. Veja o que Martin Fowler diz sobre essas coisas:

martinfowler.com/bliki/AnemicDomainModel.html


Então aí que complica qual seria a melhor escolha??

Meu projeto esta dividido:
- Model (Entidades + DAO[ô]s apenas)
- View
- ViewModel ( Entidades para relatorios e afins )
- Controllers
- Libs (classes de conexão com banco etc.. )
- assets (css,js etc..)

explicando basicamente :
No meu controller [Ô]UsuarioController[Ô] tenho uma action chamada [Ô]logar[Ô] que instancia minha entidade [Ô]Usuario[Ô] via POST recupera as informações e minha DAO [Ô]UsuarioDAO[Ô]
que é responsavel pela query de Select.. e por fim meu UsuarioController explode a view renderizada..

JABA 21/09/2017 17:32:01
#476715
Resposta escolhida
Cara, aqui você encontra tudo o que você precisa:

www.youtube.com/watch?v=i9Il79a2uBU
MESTRE 25/09/2017 07:15:48
#476753
Citação:

:
Cara, aqui você encontra tudo o que você precisa:

www.youtube.com/watch?v=i9Il79a2uBU


Obrigado Jaba..
Tópico encerrado , respostas não são mais permitidas