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> Para: delphi-br@yahoogrupos.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 [mailto:delphi...@yahoogrupos.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 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 <mailto:trindade%40desbrava.com.br> > Para: delphi-br@yahoogrupos.com.br <mailto:delphi-br%40yahoogrupos.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 <mailto:delphi-br%40yahoogrupos.com.br> [mailto:delphi-br@yahoogrupos.com.br <mailto:delphi-br%40yahoogrupos.com.br> ] Em nome de Rodrigo Rossi Enviada em: segunda-feira, 9 de agosto de 2010 17:42 Para: delphi-br@yahoogrupos.com.br <mailto:delphi-br%40yahoogrupos.com.br> ; n...@yahoogrupos.com.br <mailto:NDDV%40yahoogrupos.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 <mailto:rdrg_rossi%40hotmail.com> <mailto:rdrg_rossi%40hotmail.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]
