Então... essa é uma coisa que eu particularmente não gosto... Quero que meu cliente tenha liberdade de "navegar" entre os cadastros... Por isso que to ralando pra tentar fazer um sistema o mais "flexivel" possivel!... -- Eny Trova Urias
"Somos o que repetitivamente fazemos, portanto, a excelência não é um feito, mas um hábito"- Aristóteles ________________________________ De: Adriano de F. Trindade <trind...@desbrava.com.br> Para: delphi-br@yahoogrupos.com.br Enviadas: Quinta-feira, 12 de Agosto de 2010 8:21:48 Assunto: RES: [delphi-br] Estrutura Padrão de Software Opa! Mas eu faço isso em SDI. Se estou no cadastro de estoque e preciso cadastrar uma família de estoque, eu chamo o form de cadastro de famílias do estoque, a família é inserida, depois volta para o estoque e continua a preencher o cadastro. A diferença é o usuário só volta para o cadastro de estoque depois de concluir e fechar o cadastro de famílias, o usuário não tem liberdade para alternar de um para outro conforme sua vontade, e sim da maneira que eu determino. Desta maneira eu sei o que esperar e não perco o controle. Falou! -----Mensagem original----- De: delphi-br@yahoogrupos.com.br [mailto:delphi...@yahoogrupos.com.br] Em nome de Luciano Bruno Enviada em: quarta-feira, 11 de agosto de 2010 20:25 Para: delphi-br@yahoogrupos.com.br Assunto: Re: [delphi-br] Estrutura Padrão de Software Eu tenho aplicaçoes relativamente grandes e uso MDI. uma das coisas que eu faço é impedir que ele seja criado mais de uma vez. uma vantagem que vejo no MDI e TDI, é a liberdade de poder editar um cadastro auxiliar na ediçao de outro. tipo: no cadastro de um produto, poder cadastrar um grupo uma sessao etc. mais isso fica acriterio do desenvolvedor. Em 11 de agosto de 2010 11:36, Adriano de F. Trindade < trind...@desbrava.com.br> escreveu: > > > Ei, eu não te impus uma regra. Falei que EU trabalho assim, eu trabalho > somente com SDI. Tudo depende da maneira que a sua aplicação vai trabalhar. > Você pode trabalhar com MDI e mastigar os problemas decorrentes disso. > > E mais de um cadastro aberto de cada vez? Você tem que questionar: “você > vai precisar mexer em dois cadastros simultaneamente?” Porque a gente não > permite isso, justamente porque cada pessoa faz uma coisa de cada vez: > conclui-se um cadastro primeiro para depois abrir o próximo. Também outra > coisa é abrir duas janelas DISTINTAS ao mesmo tempo e outra é abrir a MESMA > janela mais de uma vez. > > Você tem que ver o que o cliente quer, e se é viável. Em muitos casos você > tem que mudar a cabeça do cliente para não ter que fazer um monte de > trabalho desnecessário. Só que você não consegue fazer isso sem argumentos > sólidos, consistentes e convincentes. Um deles é o custo de desenvolvimento: > “da maneira A eu faço em uma semana, da maneira B eu levo um mês porque > tenho que reescrever tudo”. > > Também é uma coisa você fazer um sistema específico para um cliente e outra > coisa radicalmente diferente é você fazer um sistema para vários clientes. > Se um cliente te exige SDI e outro te exige MDI, qual que ganha? E, > piorando, se 10 clientes exigirem MDI e 10 clientes exigirem SDI, como é que > fica? Se você optar por SDI, o quê você vai dizer para quem não quer SDI? > Vai dizer tchau? Tenha uma justificativa e ele a aceitará. Mas sem > justificativa, não vai aceitar nunca. Porque um sistema para várias empresas > jamais vai CONTENTAR á todas, mas pode ATENDER BEM á todas. E mesmo essas > que não se contentaram, depois de um tempo se acostumam e param de reclamar. > Afinal, a resistência à mudanças é uma constante, ninguém quer mudar, porque > isso dá trabalho. > > “A fórmula do sucesso eu não sei, mas a do fracasso é agradar á todos” – > Anônimo (corretíssimo) > > > Falou! > > De: delphi-br@yahoogrupos.com.br <delphi-br%40yahoogrupos.com.br> [mailto: > delphi-br@yahoogrupos.com.br <delphi-br%40yahoogrupos.com.br>] Em nome de > Eny Urias > Enviada em: quarta-feira, 11 de agosto de 2010 11:03 > > Para: delphi-br@yahoogrupos.com.br <delphi-br%40yahoogrupos.com.br> > Assunto: Res: [delphi-br] Estrutura Padrão de Software > > Entendi.... Então, realmente, não ha como trabalhar com DataModule numa > aplicação MDI? Porque foi uma das exigencias do cliente poder abrir mais de > um > cadastro de uma vez... Eu tb não gosto de trabalhar com MDI... muito > trabalhoso... mas, fazer o q... > > -- > Eny Trova Urias > > "Somos o que repetitivamente fazemos, portanto, a excelência não é um > feito, mas > um hábito"- Aristóteles > > ________________________________ > De: Adriano de F. Trindade <trind...@desbrava.com.br<trindade%40desbrava.com.br><mailto: > trindade%40desbrava.com.br <trindade%2540desbrava.com.br>> > > Para: delphi-br@yahoogrupos.com.br <delphi-br%40yahoogrupos.com.br><mailto: > delphi-br%40yahoogrupos.com.br <delphi-br%2540yahoogrupos.com.br>> > Enviadas: Terça-feira, 10 de Agosto de 2010 17:03:46 > Assunto: RES: [delphi-br] Estrutura Padrão de Software > > Minha aplicação é SDI. Bem mais simples e menos propensa á erros, tipo, um > registro ser modificado em um form e no outro você ter o mesmo dado > atualizado. > Quanto mais você deixar o usuário fazer o que ele quiser, maior serão as > possibilidades de algo dar errado. > > Mas isso é a minha opção pessoal, claro. As precauções e checagens para MDI > e > SDI são bem diferentes. Você define como você quer trabalhar. Eu tenho uma > maneira bem peculiar de trabalhar aqui, muito “old school”. > > Falou! > > De: delphi-br@yahoogrupos.com.br <delphi-br%40yahoogrupos.com.br> <mailto: > delphi-br%40yahoogrupos.com.br <delphi-br%2540yahoogrupos.com.br>> > [mailto:delphi-br@yahoogrupos.com.br <delphi-br%40yahoogrupos.com.br><mailto: > delphi-br%40yahoogrupos.com.br <delphi-br%2540yahoogrupos.com.br>> ] Em > nome > de Eny Urias > Enviada em: terça-feira, 10 de agosto de 2010 15:51 > Para: delphi-br@yahoogrupos.com.br <delphi-br%40yahoogrupos.com.br><mailto: > delphi-br%40yahoogrupos.com.br <delphi-br%2540yahoogrupos.com.br>> > Assunto: Res: [delphi-br] Estrutura Padrão de Software > > Como vc trabalha numa aplicação MDI utilizando DataModule? Se o usuário > quiser > abrir dois formularios de clientes como vc faz? Não dá conflito já que os > componentes de acesso aos dados estão no DM? > > -- > Eny Trova Urias > > "Somos o que repetitivamente fazemos, portanto, a excelência não é um > feito, mas > > um hábito"- Aristóteles > > ________________________________ > De: Adriano de F. Trindade <trind...@desbrava.com.br<trindade%40desbrava.com.br><mailto: > trindade%40desbrava.com.br <trindade%2540desbrava.com.br>> > <mailto:trindade%40desbrava.com.br <trindade%2540desbrava.com.br>> > > Para: delphi-br@yahoogrupos.com.br <delphi-br%40yahoogrupos.com.br><mailto: > delphi-br%40yahoogrupos.com.br <delphi-br%2540yahoogrupos.com.br>> > <mailto:delphi-br%40yahoogrupos.com.br <delphi-br%2540yahoogrupos.com.br>> > > Enviadas: Segunda-feira, 9 de Agosto de 2010 19:03:05 > Assunto: RES: [delphi-br] Estrutura Padrão de Software > > Não quero te desanimar, mas mostrar os problemas provoca a busca de > soluções > para eles, e com isso aprende-se. > > Pelo jeito você está meio “cru” no negócio, e a lógica, você até que está > indo bem, considerando a herança dos formulários. > > O que falta, na real, é você fracionar estes seus casos de uso aí. Explico: > DataSource, por exemplo, alguns formulários vão precisar de um, outros de 5 > e outros de 20. Se você fazer no seu modelo primário um único DataSource, > em > cada formulário que você criar herdando este formulário, terá que adicionar > mais DataSources. Mas, se você fizer o modelo com 10, aí você atende a > maioria dos casos, e em raras oportunidades terás que adicionar mais data > sources além desses 10 aí. > > Entendeu o exemplo? Eu quis dizer: projetar considerando o máximo de > possibilidades para cada form, e não o mínimo. Certo? Agora esqueça esses > data sources aí. Crie um único Data Module, com um nome bem curto (eu uso > “DM”) e coloque todos seus componentes de acesso á dados lá: > ClientDataSets, > DataModules, DataSetProviders e por aí vai. Desta maneira, você não vai ter > componentes de acesso á dados espalhados pelo seu projeto. > > Eu comecei há 5 anos atrás um sistema mais ou menos da maneira que você > estava começando este. Começou com 34 tabelas e hoje tem 220 tabelas no BD. > De todo o tempo de desenvolvimento, no mínimo 30% dele foi refazendo coisas > que fiz sem considerar todas as possibilidades. Por exemplo: ao projetar um > formulário para Notas Fiscais, você precisa de uma tabela para os dados da > NF e outra para o detalhamento da NF, que são os produtos/serviços. > Primeiro > fiz com uma tabela para produtos e outra para serviços: tive que refazer > para colocar produtos e serviços em uma única tabela. Alguns valores como > frete e seguro iam no corpo da NF. Não, não dá certo, valores de frete e > seguro tem que ser distribuídos pelos itens da NF para conseguir gerar a > NF-e direito. No corpo da NF, só dados cadastrais, dados monetários tem que > ser tudo nos itens. E tome refazer enormes partes do código. > > Minha dica pra ti é: vá para o Delphi por último. Faça funcionar no papel > primeiro. Vai lidar com Notas Fiscais? Estude o lay-out da NFe e do SPED > antes para saber de quais dados você precisará e modelar seu BD de acordo. > Sugiro usar a padronização de nomes de campos que consta no lay-out da > NF-e, > vai tornar sua vida mais fácil no futuro. Vais trabalhar com ECF? Estude o > manual do PAF-ECF. Vais gerar boletos para bancos? Estude a documentação > sobre quais dados você precisa informar nos arquivos gerados para os bancos > e use eles nas contas á pagar/receber. Quais impostos vais ter que > informar? > Campos no BD para cada um. > > É mais importante para seu projeto entrar nas empresas e ver como que todos > trabalham, que informações um departamento precisa obter do outro, o > rastreamento de quem fez o quê, o controle de acesso, permissões para os > menus, acesso de vários usuários ao mesmo tempo... Depois que tiver tudo > isso no papel, aí sim você vai pro Delphi. Porque sabendo isso tudo, aí > você > saberá quantos formulários vai precisar, quantos campos em cada formulário, > quantos ClientDataSets... Bote a prancheta embaixo do braço, esqueça a > “programação de software acadêmica” e disseque a prática das pessoas. Só > depois você vai saber o quê precisa fazer no Delphi e quais problemas terá > que solucionar DE VERDADE. > > Falou! > > De: delphi-br@yahoogrupos.com.br <delphi-br%40yahoogrupos.com.br> <mailto: > delphi-br%40yahoogrupos.com.br <delphi-br%2540yahoogrupos.com.br>> > <mailto:delphi-br%40yahoogrupos.com.br <delphi-br%2540yahoogrupos.com.br>> > > [mailto:delphi-br@yahoogrupos.com.br <delphi-br%40yahoogrupos.com.br><mailto: > delphi-br%40yahoogrupos.com.br <delphi-br%2540yahoogrupos.com.br>> > <mailto:delphi-br%40yahoogrupos.com.br <delphi-br%2540yahoogrupos.com.br>> > ] > Em > nome de Rodrigo Rossi > Enviada em: segunda-feira, 9 de agosto de 2010 17:42 > Para: delphi-br@yahoogrupos.com.br <delphi-br%40yahoogrupos.com.br><mailto: > delphi-br%40yahoogrupos.com.br <delphi-br%2540yahoogrupos.com.br>> > <mailto:delphi-br%40yahoogrupos.com.br <delphi-br%2540yahoogrupos.com.br>> > ; > n...@yahoogrupos.com.br <NDDV%40yahoogrupos.com.br> <mailto: > NDDV%40yahoogrupos.com.br <NDDV%2540yahoogrupos.com.br>> <mailto: > NDDV%40yahoogrupos.com.br <NDDV%2540yahoogrupos.com.br>> > > Assunto: [delphi-br] Estrutura Padrão de Software > > Boa tarde. > > Estou desenvolvendo já faz uns 3 meses um software em Delphi 2010 para > ERP, não é um ERP muito grande mas a idéia é atender vários ramos de > atividade, é um projeto importantíssimo para min, este software estou > desenvolvendo sozinho, como nunca fiz um projeto grande assim de delphi, > gostaria da opinião de vocês sobre alguns assuntos. > > Estou com muita dificuldade em definir a arquitetura do software (o > modelo), por exemplo, o que fiz até agora foi: > > 1 - Criar um DM para conexão com o Firebird usando SqlConnection. > 3 - Criar três formulários genéricos que serão herdados para a geração > de outros (herança de formulários). Nesses formulários coloquei um > DataSource. > 4 - Criei um cadastro de clientes herdando do formulário genério do item > 3, neste cadastro, coloquei um SqlQuery, um DataSerProvider, um > ClientDataSet e um DataSource, onde ligo um no outro e o coloco o > DataSource igual ao do Form genérico, lá no form genérico faço todos os > comandos de CRUD e também navigator usando o datasource > (dsrCadastros.DataSet as TClientDataSet). Isso achei legal pois quando > crio um novo formulário herdando do genérico só me preocupo em enviar > alguns parâmetros como: Nome da tabela, campos chave etc.. > 5 - Como viram no item 4, estou usando os componentes de conexão dentro > do formulário e não estou usando um DataModule separado para isso (EU > achei melhor, aceito sujestões). > > Gostaria de saber de vocês se isso que estou fazendo está certo, se é > isso que acontece na prática, trabalho com programação em linguagem > própria e estou no segundo ano de informática, nunca trabalhei com > delphi em nenhuma empresa por isso estou com essas dificuldades. Já > tenho alguns projetos prontos em delphi mas nada se compara a este. > > Ainda tenho que colocar no sistema: > > 1 - Parte multiusuário: Como vocês fazem isso com firebird? Tentei > colocar DataSnap no meu projeto mas vi que teria que mudar toda a > estrutura que já fiz, ia dar muito trabalho, então somente fiz um arqivo > .ini que o usuário indica onde é o servidor e o arquivo do firebird > (*.fdb;*.gdb). > 2 - Permissão de usuário nas telas: Quero fazer uma tela principal com > botoes, gráficos, atalhos para relatórios, etc. Mas como vou fazer o > gerenciamento disso, por exemplo, o usuário A não pode ver as vendas do > mês e na tela principal tem um botão la que mostra as vendas por mês. > > OBSERVAÇÃO: Eu até sei como resolver a maioria desses problemas, a parte > da lógica é facil, o que estou com dificuldades é COMO resolver esses > problemas, como definir uma estrutura que quando o projeto crescer não > terei que fazer uma mudança grande para atender um requisito, quero > reaproveitamento de código. > > Abraços..... > > -- > Att. > > Rodrigo Rossi > Skype: rodrigotrentinrossi > MSN: rdrg_ro...@hotmail.com <rdrg_rossi%40hotmail.com> <mailto: > rdrg_rossi%40hotmail.com <rdrg_rossi%2540hotmail.com>> <mailto: > rdrg_rossi%40hotmail.com <rdrg_rossi%2540hotmail.com>> > <mailto:rdrg_rossi%40hotmail.com <rdrg_rossi%2540hotmail.com>> > > Fone: (45) 9963-1897 > Cascavel - PR > > [As partes desta mensagem que não continham texto foram removidas] > > [As partes desta mensagem que não continham texto foram removidas] > > [As partes desta mensagem que não continham texto foram removidas] > > [As partes desta mensagem que não continham texto foram removidas] > > [As partes desta mensagem que não continham texto foram removidas] > > > -- Luciano S. Bruno Consultor em TI [As partes desta mensagem que não continham texto foram removidas] ------------------------------------ -- <<<<< FAVOR REMOVER ESTA PARTE AO RESPONDER ESTA MENSAGEM >>>>> [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
