Tentando evoluir meu nível de conhecimento em Java, me dediquei a realizar um projeto com objetivo deste estar em arquitetura MVC. Entendo que ela não é a ideal para miniprojetos, mas gostaria de estar aprendendo sobre ela e sua dinâmica (afins acadêmicos/auto didático).
Entretanto, neste meio tempo me veio uma dúvida… Os ícones de meu programa sei que devem estar na pasta com referencia a imagens (ex: images,imagens), mas não sei onde é que esta pasta ‘images’ deve ficar localizada dentro de meu programa.
Seria no pacote Model? Se sim, poderiam me explicar o motivo?
Sua pergunta é pertinente. Não importa muito desde que haja um padrão. Pode ser /resources/img por exemplo. O mais importante é view estar correta, e lendo de uma fonte de recursos organizada.
Os ícones em si não fazem parte da camada view. São apenas recursos para ela. A camada view vai acessar o repositório de de recursos e media para montar a interface.
Parece que sim, mas sua IDE eu não conheço. A indústria adota o padrão maven para organizar as pastas, que eh um pouco diferente de como você fez.
Sim, pode criar mais pastas do que estas 3. Pode ter uma integration por exemplo, com clientes de suas integrações, ou uma “repository” para persistência de dados, util para útil, etc… Abs.
Após ler seu comentário, realizei alguns estudos didáticos referente a organização de pacotes (patteners) no Java, e me deparei com a situação ‘com.nomeempresa.nomepacote.nomesubpacote’
Confesso não ter visto isso ainda, afins de melhor meu conhecimento pensei numa metodologia para criar os pacotes e atribuir o que está dentro desse programinha que estou fazendo:
Bloco de Citação
Ficando então assim a criação da pasta:
Bloco de Citação
programa (nome do app a ser desenvolvido)
com.br.empresax.sofware (nome do pacote)
com.br.empresax.sofware.controller (onde ficara a conexao do app com o banco de dados)
|-com.br.empresax.sofware.controler.conexaobd
com.br.empresax.sofware.model
|-com.br.empresax.software.model.classes (onde ficara as classes com seus getter e setters)
|-com.br.empresax.sofware.model.dao (onde ficará SQL de conexao (crud) com o bando de dados)
com.br.empresax.sofware.view (onde ficara somente minhas telas)
com.br.empresax.sofware.resoucers (onde ficarao os recursos)
|-com.br.empresax.sofware.resoucers.images (onde ficará as imagens a serem usadas nas jframs)
|-com.br.empresax.sofware.resoucers.consultasxml (onde ficará minhas consultas de sites em xml, onde passará o resultado para os setters… exemplo: Busquei o CEP de webservice xml, pegarei este resultado e passarei para os setters da classe Endereco)
|-com.br.empresax.sofware.resoucers.consultasjson (mesmo objetivo da classe ‘consultasxml’)
com.br.empresax.sofware.dependences (onde ficarao todos os arquivos .jar importados (como ‘json-simple’;javax.mail; etc)
Poderia me confirmar se estaria correto desenvolver com este padrão?
O “Certo” seria br.com.empresa.software.
Coloquei “Certo” entre parênteses por se tratar apenas de uma convenção. Mas é bom seguí-la pois assim você nunca vai evitar perder tempo discutindo o sexo dos anjos com outros desenvolvedores.
Eu usaria repository (de repositório de dados) ao invés de conexaobd.
Não precisa. Quase todos os seus arquivos são classes.
Não precisa estar dentro de um pacote. No maven/gradle vc configura uma pasta para ser resources, dizendo que ela será parte do empacotamento do projeto.
Eu criaria um pacote “br.com.empresa.software.integration” e la dentro subpacotes com todas as integrações que você tiver.
Sugestão 1: comece imediatamente usar maven para aprender mais sobre a estrutura das pastas. Tem um monte de convenção da indústria que vem do Maven. Quando ficar especialista nele, comece usar Gradle (que eh melhor e usa o padrão criado com o maven).
Sugestão 2: comece ler o livro “Clean Code”, devagar sem pressa. Cuide para não utilizar as coisas demais, adapte pra sua realidade, opte sempre pela simplicidade.
Sugestão 3: se você fizer algo errado na estrutura, eh muito simples de corrigir depois. As IDEs tem recursos de refactoring que fazem 90% do trabalho automático.