GHSilva wrote:Caro amigo rcalcado,

É até estranho debater este assunto dessa forma pois parece que estou falando de laranjas e você de bananas.. rs

São arbitrários porque não fazem sentido dentro do sistema de tipos, eles "quebram as regras", trapaceiam.

Quanto as chamadas "trapaças" acredito que seja um infeliz comentário pouco embasado não somente no texto PDF que você mandou o qual na página 4, cita a linguagem C como também fracamente tipada entretanto não impediu que fosse largamente utilizada até mesmo para desenvolver SO´s até hoje, nao é mesmo?

GHSilva wrote:
Conforme havia dito antes bons programadores aprendem a utilizar a linguagem e não adequam a sintaxe ao seu uso.

GHSilva wrote:
E não os casts não são arbitrários

GHSilva wrote:
...
POG que é POG nao precisa usar o PHP pra fazer cagada.. Faz em qualquer uma! Assim como o bom programador faz um codigo seguro usando as particularidades do PHP, sem problema algum.

Desculpe se ofendi alguém, não foi intencional.. Só não fiquem bitolados em uma única vertente.. mente aberta!.. rs

carol_programadora wrote:
Se nas minhas classes de controller, quando eu preciso de alguma consulta direta, sem ter negócio envolvido, inclua aqui dados brutos para popular comboBox, DataTable... etc eu tinha pensando em injetar uma dependência "UsuarioDao" no meu "UsuarioController" e não um UsuarioRepository... achei que fosse errado colocar uma dependência do repository no controller, achei que elas deveriam ser usada APENAS por classes do domínio, por domínio quero dizer as entities e os services, então eu pensei que o controller não deveria ter esse contato.
Então creio que estou errada, utilizando sua sugestão Shoes, minha única opção pra inserir dentro do "UsuarioController" seria minha "UsuarioRepository.

carol_programadora wrote:
Dentro de Application e Domain, tem pacote "service", pelo que li e entendi até agora(a não ser que fiz bagunça) minhas regras de negócio devem ficar no Domain > Service, certo?!

carol_programadora wrote:
Fiquei confusa com essa camada "Application", não tinha visto sobre ela no DDD, e na verdade pouco conheço ainda dela no geral

DDD, Capítulo IV wrote:
* User Interface (or Presentation Layer): Responsible for showing information to the user and interpreting the user's commands. The external actor might sometimes be another computer system rather than a human user.

* Application Layer: Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems. This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program.

* Domain Layer (or Model Layer): Responsible for representing concepts of the business, information about the business situation, and business rules. State that reflects the business situation is controlled and used here, even though the technical details of storing it are delegated to the infrastructure. This layer is the heart of business software.

* Infrastructure Layer: Provides generic technical capabilities that support the higher layers: message sending for the application, persistence for the domain, drawing widgets for the UI, and so on. The infrastructure layer may also support the pattern of interactions between the four layers through an architectural framework.

carol_programadora wrote:
Nos no meu "UserRepository" eu tenho algo mais relacionado ao negócio, suponhamos que eu precise de encontrar "Todos usuários com salário > 5.000, que tenham Casa própria quitada, que não tenha filhos, seja solteiro etc etc"(considere que seja uma consulta bem complexa) e lá na interface repository eu terei este método "findUsersBemDeVida();

Até ai ok, pois representa algo bem espefíco, mas agora se eu estiver usando este modelo:

UsuarioRepository > UsuarioDecorator(implements UsuarioRepository) > UsuarioDao

carol_programadora wrote:
Onde ficará meu SQL(HQL seja o que for) dessa consulta?

cv wrote:

pedromuyala wrote:MVC está presente na Camada de Apresentação.

Er, nao. O 'V' de MVC *é* a camada de apresentacao.

ravisantos wrote:
Philip, muitos questionam o uso do Repository com o Dao ou seja o Repositorio sendo um interface para o Dao. Dizem que o dao neste caso nao faz sentido bastando ter por composicao dentro do repositorio, uma Session ou EntityManager.

O que você pensa desta abordagem?

ravisantos wrote:Olá, Philip e qual bibliografia seria recomendada?

thimor wrote:aplicando essa filozifia como ficaria entao um programa web usando mvc?