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 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ê > 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]
