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.brtrindade%40desbrava.com.brmailto: trindade%40desbrava.com.br trindade%2540desbrava.com.br Para: delphi-br@yahoogrupos.com.br delphi-br%40yahoogrupos.com.brmailto: 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
Re: [delphi-br] Estrutura Padrão de Software
Bom, eu uso TDI e não tenho do que reclamar, logo que viram alguns dizerem, e quando a tela é pequena e tem poucos campos, fica aquele espaço todo vazio, bom, dane-se o espaço vazio, se vc abre o word ele abre com uma folha inteira em branco... a folha naum vai ficando maior de acordo com o que vc digita... rs Mas... cada um tem seu estilo... Veja esses prints... http://www.jmsoftwares.com.br/erp O usuário abre quantas janelas quiser, só não mais de uma da mesma... rs Att, Jhosef Marks de Carvalho Blog: http://www.jhosefmarks.com.br Jesus está voltando E se o meu povo, que se chama pelo meu nome, se humilhar, e orar, e buscar a minha face e se converter dos seus maus caminhos, então eu ouvirei dos céus, e perdoarei os seus pecados, e sararei a sua terra. (2 Cr 7:14) Em 12 de agosto de 2010 08:21, Adriano de F. Trindade trind...@desbrava.com.br escreveu: 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 delphi-br%40yahoogrupos.com.br [mailto: delphi-br@yahoogrupos.com.br delphi-br%40yahoogrupos.com.br] Em nome de Luciano Bruno Enviada em: quarta-feira, 11 de agosto de 2010 20:25 Para: delphi-br@yahoogrupos.com.br delphi-br%40yahoogrupos.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 trindade%40desbrava.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.brdelphi-br% 40yahoogrupos.com.br [mailto: delphi-br@yahoogrupos.com.br delphi-br%40yahoogrupos.com.brdelphi-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.brdelphi-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
Re: [delphi-br] Estrutura Padrão de Software
Com MDI verdadeiro e usando datamodules, nao sei. Provavelmente nao vai funcionar pois vais perder a referencia do clientdataset ou equivalente para uma janela ou outra. Porém, na antiga empresa que trabalhavamos, simulavamos a funcionalidade do MDI, que nada mais era no caso que desenhar um form e ter uma barra lateral com a lista dos forms abertos. Porem tinhamos um framework que fazia todo o processo e gerenciamento disso. E quanto a datamodules, não eramos xiitas. Haviam alguns datamodules genericos, porem colocavamos componentes de acesso a dados nos forms. isso tornou facil habilitar a abertura de varias janelas iguais acessando os mesmos dados. Cada uma em seu escopo de transação. E quando alguem atualizava um registro numa janela, a outra era atualizada automaticamente, via mensagens internas do framework. É claro que esse framework nao surgiu do dia pra noite. Mas funcionava de forma excelente. Tinhamos tambem carga dinamica de bpls, onde carregavamos e descarregavamos as bpls conforme a necessidade. Isso tudo tornava o programa leve, e rápido. Como o framework era proprietário, provavelmente vc não vai achar o mesmo disponível em lugar algum. Porem achei válido citar a experiência. Alexandre Pedroto Em 11 de agosto de 2010 11:03, Eny Urias enyur...@yahoo.com.br escreveu: 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.brtrindade%40desbrava.com.br Para: delphi-br@yahoogrupos.com.br delphi-br%40yahoogrupos.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@yahoogrupos.com.br delphi-br%40yahoogrupos.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 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.brtrindade%40desbrava.com.br mailto:trindade%40desbrava.com.br trindade%2540desbrava.com.br Para: delphi-br@yahoogrupos.com.br delphi-br%40yahoogrupos.com.brmailto: 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
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.brtrindade%40desbrava.com.brmailto: trindade%40desbrava.com.br trindade%2540desbrava.com.br Para: delphi-br@yahoogrupos.com.br delphi-br%40yahoogrupos.com.brmailto: 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.brmailto: 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.brmailto: 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.brtrindade
RES: RES: [delphi-br] Estrutura Padrão de Software
Opa! Olha, cara, eu não uso BPL. Criei uma pasta e todos os arquivos do sistema (mais de 800) estão nela. Como o Delphi gerencia isso, você não precisa se preocupar com os arquivos. Jogue o arquivo INI na mesma pasta, porque quando você distribuir sua aplicação, é só colocar ele na mesma pasta do EXE principal e valeu. E o DataModule é um só para todo o projeto. Eu tenho um único DataModule para mais de 500 forms aqui. Tente não complicar o que pode ser simples, desde que isso não prejudique sua organização. Estrutura que te agrade? Isso será resultado da sua experimentação. E vai mudar á medida que você adquirir conhecimento. Se eu fosse reescrever hoje este sistema aqui do zero, ele seria MUITO diferente, hehehehe. Falou! De: delphi-br@yahoogrupos.com.br [mailto:delphi...@yahoogrupos.com.br] Em nome de Rodrigo Rossi Enviada em: terça-feira, 10 de agosto de 2010 08:30 Para: delphi-br@yahoogrupos.com.br Assunto: Re: RES: [delphi-br] Estrutura Padrão de Software Entendi Adriano... Eu to meio perdidão mesmo na estrutura que terei que montar, programar e lógica é facil, o problema é como fazer da melhor maneira sabe Aproveitando, gostaria de algumas dicas de como posso organizar meu sistema em pacotes BPL, já sei como criar pacotes, adicionar ao projeto... bla...bla...bla... mas gostaria de saber como vocês separam isso, é por módulo? Se sim voces criam um DM para cada projeto? Eu tenho um arquivo .INI que o sistema lê antes de conectar na base, em qual BPL posso deixar esse arquivo? E a organização de pastas com os arquivos do delphi (PAS, DCU, DCP) como voces organizam isso? Ainda não consegui achar a estrutura que me agrade Att. Rodrigo Rossi Skype: rodrigotrentinrossi MSN: rdrg_ro...@hotmail.com mailto:rdrg_rossi%40hotmail.com Fone: (45) 9963-1897 Cascavel - PR On 09/08/2010 19:03, Adriano de F. Trindade wrote: 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ê
[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 Fone: (45) 9963-1897 Cascavel - PR
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 [mailto:delphi...@yahoogrupos.com.br] Em nome de Rodrigo Rossi Enviada em: segunda-feira, 9 de agosto de 2010 17:42 Para: delphi-br@yahoogrupos.com.br; n...@yahoogrupos.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
