| Autor |
Mensagem |
|
|
|
Ele esta dizendo que a propriedade tbSegPerfils nao existe no mapeamento da classe tbSegUsuario. E realmente nao está no xml que vc postou.
|
 |
|
|
|
Qual eh a mensagem de erro?
|
|
|
|
thegoergen wrote:
Só que tem mais um detalhe, quandtos empregados você conhece que tem uma esposa 20 anos mais jovens, siliconada, que fica fazendo compras no shopping enquanto o marido vai jogar têncis com a Elite e anda de carro importado? Nenhum.
A nao ser, eh claro, que o cara tenha um talento impressionante pro tenis, nao vai ser assim que ele vai ganhar dinheiro. Pra ficar o dia inteiro na boa, ou sendo filho de milhonario, e sem compromisso nenhum, ou sendo personagem de novela. Empresario que tenta fazer isso se quebra rapidinho.
|
|
|
|
Exatamente como o Carlos falou, vc vai usar um command para cada acao, herdado de uma interface command:
por ex:
E os commands que implementarao essa interface
|
|
|
|
|
O problema eh que pra ter sua propria empresa nao basta saber programar. Administrar recursos financeiros, gerenciar pessoas, saber negociar precos e prazos, saber cobrar os devedores... Isso tudo eh mto complexo e vc nao tem tempo para aprendizado normalmente. Quando vc ve que errou a coisa ja foi pro buraco.
|
|
|
|
Como dizem as definicoes por ai. Design Patterns sao solucoes recorrentes para problemas recorrentes. Nos nao sabemos quais sao seus problemas, por isso nao podemos dizer quais os patterns vc pode/deve usar.
O que nós sabemos um pouco, e bem pouco, eh quais sao os requisitos. O seu problema parece estar em definir e organizar o seu dominio.
Algumas sugestoes de literatura:
http://www.amazon.com/gp/search?index=books&linkCode=qs&keywords=0321125215
http://www.amazon.com/gp/search?index=books&linkCode=qs&keywords=0321268202
E um mais pra quem esta iniciando em orientacao a objeto, nao sei eh o seu caso:
http://www.livrariasaraiva.com.br/produto/produto.dll/detalhe?pro_id=1568186&ID=BD2016B07D80C061707090996&PAC_ID=18671
|
|
|
|
Eu entendo que para persistir as infos no banco de dados, eu precisaria de uma tabela adicional para relacionar corretamente o Pedido com os itens do pedido, porém, não vi necessidade em criar uma classe adicional para cuidar dos itens. A própria Pedido não pode conter uma coleção dos itens (Produto) comprados ?
A principio parece logico pedido ter uma lista de produtos. Mas onde ficariam as informacoes com relacao a quantidade, preco de venda (especifico desse pedido, que pode ser diferente no pedido, e sera com certeza quando mudar o preco do produto). Voce muito provavelmente vai precisar de uma classe para guardar as informacoes que nao estarao nem no pedido nem no produto.
|
|
|
|
So pra me meter na discussao sobre TDD:
Nao tenho nada contra um pouco de design ja de inicio. Um esboco pra se ter nocao do relacionamento das entidades, pra se ter uma visualizacao geral desses relacionamentos. Se for preciso, faca. Mas nao se aprofunde, nao tente visualizar detalhes da implementacao que vc vai estar jogando tempo, o que é precioso, pela janela. 90% das vezes, quando vc for implementar o que esta diagramado voce vai enxergar formas melhores de fazer. É nesse ponto que entra TDD, vc escreve os testes dessas funcionalidade, e soh o fato de escrever os testes ja te dá uma boa nocao sobre o que e como essa funcionalidade vai fazer.
Se esse for um projeto real, com prazo bem definido, o que normalmente significa curto. Faca do jeito que sabe e entregue dentro do prazo. Voce vai poder ajustar depois, muitas vezes nao eh tao complexo quanto parece.
Se for um projeto de aprendizado nao ha hora melhor pra dar uma olhada em TDD. Nao se preocupe, ele em nada conflita com DDD, pelo contrario.
O conceito de TDD eh simples e nao exige um estudo de 1000 paginas sobre um milhao de patterns. Mas eh uma tecnica de desenvolvimento diferente das formas habituais e que exige muita disciplina do desenvolvedor. Ela pode ajudar sim na construcao de um modelo mais elegante. Só é preciso cuidado pra que nao vire um caos, e o desenvolvedor pense que pode sair escrevendo codigos pra todo lado, sem um rumo definido.
Resumindo, o conceito é simples, a pratica nem tanto. Se voce tiver tempo nesse projeto eu recomento, porque alem de ser util é divertido.
|
|
|
|
Leonardo3001 wrote:Nota: se você não entendeu o Marcio Duran, não se preocupe, você não é o único.
hugonardo wrote:
2. É correto ter na implementação de cada método das classes concretas de NotaState todo o negócio da transição de estado? Por exemplo, ao cancelar uma nota fiscal Faturada, eu devo cancelar as Contas a Pagar/Receber geradas por esta nota antes de cancelá-la (entenda este processo como, para cada Conta a Pagar/Receber eu devo atualizar seu estado no Banco de Dados e em seguida alterar o estado da nota fiscal e persistí-lo também).
Não existe o "correto", mas a sua escolha faz sentido e não tem problema nenhum.
Sera que é responsabilidade da NF, ou ainda dos estados da NF, controlar toda a logica de cancelamento da nota fiscal?
hugonardo wrote:
Este procedimento de persistência deve ser chamado pelo método "cancelar()" da classe concreta Faturada? Ou este método vai apenas me retornar um "sim" ou "não" para executar o procedimento?
Melhor ainda, porque não dar à classe concreta Faturada uma instância de um DAO? Tipo, coloca um parâmetro de DAO no construtor, e, ao chamar cancelar(), é invocado no final apenas uma linha do método do DAO.
Sera que é uma boa o teu dominio conhecer objetos da infraestrutura? Particularmente nesse caso eu preferiria uma exceção ou por a NF num estado de "erro", dependendo do caso.
hugonardo wrote:
A princípio implementar todo o procedimento dentro do método "cancelar()" me pareceu mais correto, já que a intenção do padrão State é facilitar a transição de estados diminuindo o número de testes e deixando mais coeso o tratamento de cada transição.
Sim, você está certo.
Discordo novamente. A intencao do padrao State é controlar e validar a mudanca do estado do objeto, o que deve ser feito em consequencia desta mudanca do estado ou nao (caso nao seja valida) nao é problema dele.
hugonardo wrote:
Porém, o Analista que me passou este trabalho me recomendou que eu não fizesse a parte de persistência através dos métodos de NotaState, mas sim a partir do meu Controller.
Mande seu analista tomar no &*)@!
Esse "controller" é invenção de gente que não sabe OO e só ouviu falar de MVC, mas não sabe o que é.
Seja la o nome que for dado ao objeto (controller, facade, service, etc...) é uma solucao possivel. Particularmente acho melhor que a dos states controlando tudo.
hugonardo wrote:
O State está me servindo simplesmente como alguém que só me diz "pode fazer isto" ou "não pode fazer isto". Desta maneira, em alguns casos, tenho que fazer a "gambiarra" de guardar o Estado anterior para saber o que caminho devo seguir.
Ou seja, está apenas fingindo seguir design patterns e príncipios de OO. As classes que implementam State podem tomar voz ativa em suas decisões. Claro, não pode fazer tudo, pra isso você pode separar responsabilidades em outras classes. Mas dizer que o estado só pode "dizer" e não "fazer" remete ao objetos anêmicos, porém em versão "power".
Discordo de novo, qualquer coisa que um state faca que va alem do seu papel como state é atribuicao de responsabilidade que nao lhe pertence.
|
|
|
|
Provavelmente havera mais regras para o addFilho(Filho f) do que simplesmente saber se o pai existe, e essas regras ficariam estranhas se fossem colocadas no repositorio de filhos. Alem de que vc parte de cabeca para um implementacao procedural. Nada contra desde que vc saiba exatamente o que esta fazendo e as consequencias disso.
Sera que esse minimo benficio que vc teria economizando uma chamada ao banco compensa a fuga da implementacao logica da regra.
|
|
|
|
Na minha opiniao foi mal projetada a interface, ele deveria conter os metodo addForeignKey ect... e recebendo a interface como parametros.
Se vc nao tem acesso e nao vai poder mudar a interface, prepare-se pra ter dor de cabeca na hora de usar, ou nao use a interface pq ele so vai gerar mais trabalho, visto que vc vai ter que fazer casting e testar o tipo de qualquer forma, entao esqueca a interface e use as classes concretas.
Se voce pode alterar a interface nao pense duas vezes.
Essa é minha humilde opiniao, outras podem ser divergentes.
|
|
|
|
Se vc faz referencias a classe concreta tem algo de errado na sua abordagem. Se vc esta utilizando algo da classe concreta de duas uma, ou a interface esta incompleta ou voce nao esta usando a interface, mas a classe concreta, e esta tentando faze-la caber na interface, só que ela nao cabe.
E preciso ver no seu problema qual dos dois casos esta acontecendo.
|
|
|
|
Relendo eu entendi, hehehe. Curioso nao?
Guardar no banco vc diz, como stored procedures, ou em forma de texto pra que a aplicacao interprete e execute? No primeiro caso, acho pouco aconselhavel, principalmente pq os calculos nao devem ser simples, entao serao melhor executados na aplicacao.
No segundo caso nao vejo problema nenhum.
|
|
|
|
Nao entendi bem o que vc precisa.
Essas formulas serao usadas pela aplicacao? Ou serao apenas armazenadas para um usuario ver, "copiar" e aplicar a formula externamente?
|
|
|
|
|
* Esqueci de "quotar", mas eu estava falando dos livros do Ferryman.
|
|
|
|
|
|