Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da .net Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
dê seu feedback
post favorito
Arquitetura de Projetos - Artigo Revista .Net Magazine 83
O artigo demonstra os conceitos de arquitetura de projetos aplicando a modularização do desenvolvimento para que a aplicação final seja fácil de modificar, configurável e flexível. Também demonstra como fazer isto com o Visual Studio 2010 mostrando como se criar vários projetos relacionados. Alguns conceitos de arquitetura de aplicações serão expostos durante o mesmo para validar a abordagem que foi dada no exemplo.
.net Magazine 83
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da .net Magazine 83
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da .net Magazine 83
Arquitetura de Projetos
Separando um projeto em módulos
Do que trata o artigo
O artigo demonstra os conceitos de arquitetura de projetos aplicando a modularização do desenvolvimento para que a aplicação final seja fácil de modificar, configurável e flexível. Também demonstra como fazer isto com o Visual Studio 2010 mostrando como se criar vários projetos relacionados. Alguns conceitos de arquitetura de aplicações serão expostos durante o mesmo para validar a abordagem que foi dada no exemplo.
Para que serve
A modularização procura separar cada aspecto ou funcionalidade da aplicação em uma parte bem definida e até onde é possível, independente das demais. Com isto, caso seja necessário fazer manutenção no programa, se houver uma baixa dependência entre os módulos (baixo acoplamento como será visto), será mais fácil de executar sem comprometer outras partes que não precisam ser alteradas.
Em que situação o tema é útil
O tema é útil caso seja necessário criar aplicações em que suas partes funcionais sejam independentes e reutilizáveis dentro do mesmo projeto ou dentro de outros. Também permite que se separe interface, acesso a bancos e regras de negócio em partes distintas sendo que os componentes mais estruturais como a comunicação com o banco de dados, possam ser aproveitados em outros tipos de projetos.
Resumo do DevMan
Sempre que uma aplicação nova é iniciada todos os envolvidos desejariam que esta fosse definitiva e que seus requisitos e limites fossem claramente estabelecidos e, uma vez concluída, nenhuma modificação fosse necessária permanecendo o código original intacto. No mundo real isto é raro – se não impossível – de se atingir. Todos os projetos precisam passar por modificações para adaptar-se às mudanças ou corrigir problemas encontrados.
Os princípios de arquitetura procuram servir de guias para se atingir um alto índice de modularidade das aplicações. Com a modularidade, o software passa a ser tratado como um produto no qual cada uma das partes é independente sendo que, do perfeito encaixe e integração entre as partes é que ao final, se tem um bom ou mau produto. Para atingir um alto grau de desacoplamento das partes, sendo que cada uma funciona independentemente sem precisar conhecer como outras partes funcionam, deve-se observar como as classes e os métodos são escritos. Como os dados estão estruturados e como isto estará acessível a outros módulos e projetos. O Visual Studio oferece facilidades para a implementação destes conceitos.
Preparando para a mudança
Aplicações e softwares precisam mudar. Sempre. E quanto mais rápido se adaptarem aos novos requisitos, maior será a sua longevidade visto que quanto mais flexível e adaptado para as necessidades dos seus usuários, melhor. Uma das formas de se conseguir isto é dar uma atenção contínua a excelência técnica e ao bom design. Desta forma se atinge um nível alto de agilidade no desenvolvimento e na resposta as mudanças necessárias.
Agilidade se atinge também separando o programa e partes menores que são chamadas de módulos. Um programa modular divide responsabilidades e funcionalidades em pequenas partes independentes conectadas entre si através de interfaces bem definidas enquanto que, em um programa monolítico, o menor componente é o programa inteiro.
Programas modulares devem possuir um baixo acoplamento o que representa o quanto uma classe depende da outra para funcionar. Quanto maior for esta dependência entre ambas, mais acopladas estarão. O forte acoplamento traz problemas. Uma aplicação modular é aquela dividida em um conjunto de unidades funcionais - chamados de módulos - que pode ser integrados em uma aplicação extensa.
Considerando por exemplo um sistema para emissão de pedidos de venda cujo código para acesso ao banco de dados está vinculado com a aplicação Windows que provê a interface para a edição de dados. Não raro, este código pode estar inserido inclusive dentro do próprio formulário que faz a edição.
Caso seja necessário mudar-se o gerenciador do banco de dados a aplicação Windows precisará também passar por mudanças. Mais problemático ainda é se esta aplicação for usada por vários clientes, e enquanto alguns usam um banco, outras, usarão outro.
Para poder implementar a modularização de maneira eficiente é importante conhecer alguns princípios de arquitetura de software.
Arquitetura de software
Arquitetura de software envolve decisões significativas sobre a organização do software incluindo a seleção de elementos estruturais e suas interfaces. Também envolve funcionalidade, usabilidade, resiliência (o quanto a aplicação é flexível), desempenho, capacidade de reuso dos componentes, compreensibilidade, limitadores econômicos e tecnológicos, conceitos estéticos e de mercado.
O risco de uma arquitetura mal elaborada pode tornar o software instável e incapaz de suportar requisitos existentes ou futuros do negócio para o qual é desenvolvido ou ainda, difícil de implantar ou gerenciar no ambiente de produção. Arquitetura cuida de como os principais elementos dentro do software são interligados.
Eis algumas das questões que a arquitetura do software leva em consideração:
• Como os usuários usarão a aplicação? Todos usarão o mesmo conjunto de hardware + software?
• Como a aplicação será implantada e gerenciada no ambiente de produção?
• Qual o nível de qualidade requerido pela aplicação quanto aos itens como: segurança, desempenho, concorrência, internacionalização e configuração?
• Como a aplicação pode ser desenvolvida para ser flexível e possa ser mantida ao longo do tempo?
• Quais são as tendências da arquitetura que poderão causar impacto na aplicação atualmente ou após ela ter sido implantada?
Com estes itens em mente já é possível começar a delinear como a aplicação deve ser escrita. Para auxiliar, alguns dos princípios da arquitetura também permitem estabelecer os padrões:
• Construa preparando para mudança em vez de desenvolver para manter como foi feito.
• Faça modelagem para analisar e reduzir riscos. A modelagem ajuda principalmente em casos onde existirá a possibilidade de usar vários meios para se gravar os dados. Ao se definir os nomes das colunas e os tipos de dados, já se começa a verificar limitações e riscos que poderão ser encontrados.
• Use os modelos e visualizações como ferramentas para comunicação e colaboração.
• Identifique as principais decisões de engenharia a serem tomadas.
Arquitetura é focada em organizar os componentes para suportar uma funcionalidade específica. Se estiver sendo escrita uma classe para armazenar dados, é isto o que a mesma deve fazer e somente isto. A classe não deve e nem precisa saber como estes dados são recuperados ou persistidos no disco, na rede ou mesmo na nuvem.
Durante esta fase é que pode se identificar se vai se desenvolver os componentes necessários internamente ou se serão adquiridos de terceiros. Em alguns casos, isto pode gerar uma grande economia de tempo e dinheiro.
Para os que estão envolvidos com o design, alguns princípios desta área podem ajudar a organizar o trabalho possibilitando benefícios como diminuição de custos – através de um desenvolvimento mais ágil – e promoção da usabilidade do software:
• Separação de responsabilidades. Para promover um baixo acoplamento, cada parte deve fazer o mínimo possível.
• Princípio da responsabilidade por um único aspecto. Cada componente deve ser responsável unicamente por uma funcionalidade ou característica específica ou agregação ou funcionalidade coesa.
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
Separando um projeto em módulos
Do que trata o artigo
O artigo demonstra os conceitos de arquitetura de projetos aplicando a modularização do desenvolvimento para que a aplicação final seja fácil de modificar, configurável e flexível. Também demonstra como fazer isto com o Visual Studio 2010 mostrando como se criar vários projetos relacionados. Alguns conceitos de arquitetura de aplicações serão expostos durante o mesmo para validar a abordagem que foi dada no exemplo.
Para que serve
A modularização procura separar cada aspecto ou funcionalidade da aplicação em uma parte bem definida e até onde é possível, independente das demais. Com isto, caso seja necessário fazer manutenção no programa, se houver uma baixa dependência entre os módulos (baixo acoplamento como será visto), será mais fácil de executar sem comprometer outras partes que não precisam ser alteradas.
Em que situação o tema é útil
O tema é útil caso seja necessário criar aplicações em que suas partes funcionais sejam independentes e reutilizáveis dentro do mesmo projeto ou dentro de outros. Também permite que se separe interface, acesso a bancos e regras de negócio em partes distintas sendo que os componentes mais estruturais como a comunicação com o banco de dados, possam ser aproveitados em outros tipos de projetos.
Resumo do DevMan
Sempre que uma aplicação nova é iniciada todos os envolvidos desejariam que esta fosse definitiva e que seus requisitos e limites fossem claramente estabelecidos e, uma vez concluída, nenhuma modificação fosse necessária permanecendo o código original intacto. No mundo real isto é raro – se não impossível – de se atingir. Todos os projetos precisam passar por modificações para adaptar-se às mudanças ou corrigir problemas encontrados.
Os princípios de arquitetura procuram servir de guias para se atingir um alto índice de modularidade das aplicações. Com a modularidade, o software passa a ser tratado como um produto no qual cada uma das partes é independente sendo que, do perfeito encaixe e integração entre as partes é que ao final, se tem um bom ou mau produto. Para atingir um alto grau de desacoplamento das partes, sendo que cada uma funciona independentemente sem precisar conhecer como outras partes funcionam, deve-se observar como as classes e os métodos são escritos. Como os dados estão estruturados e como isto estará acessível a outros módulos e projetos. O Visual Studio oferece facilidades para a implementação destes conceitos.
Preparando para a mudança
Aplicações e softwares precisam mudar. Sempre. E quanto mais rápido se adaptarem aos novos requisitos, maior será a sua longevidade visto que quanto mais flexível e adaptado para as necessidades dos seus usuários, melhor. Uma das formas de se conseguir isto é dar uma atenção contínua a excelência técnica e ao bom design. Desta forma se atinge um nível alto de agilidade no desenvolvimento e na resposta as mudanças necessárias.
Agilidade se atinge também separando o programa e partes menores que são chamadas de módulos. Um programa modular divide responsabilidades e funcionalidades em pequenas partes independentes conectadas entre si através de interfaces bem definidas enquanto que, em um programa monolítico, o menor componente é o programa inteiro.
Programas modulares devem possuir um baixo acoplamento o que representa o quanto uma classe depende da outra para funcionar. Quanto maior for esta dependência entre ambas, mais acopladas estarão. O forte acoplamento traz problemas. Uma aplicação modular é aquela dividida em um conjunto de unidades funcionais - chamados de módulos - que pode ser integrados em uma aplicação extensa.
Considerando por exemplo um sistema para emissão de pedidos de venda cujo código para acesso ao banco de dados está vinculado com a aplicação Windows que provê a interface para a edição de dados. Não raro, este código pode estar inserido inclusive dentro do próprio formulário que faz a edição.
Caso seja necessário mudar-se o gerenciador do banco de dados a aplicação Windows precisará também passar por mudanças. Mais problemático ainda é se esta aplicação for usada por vários clientes, e enquanto alguns usam um banco, outras, usarão outro.
Para poder implementar a modularização de maneira eficiente é importante conhecer alguns princípios de arquitetura de software.
Arquitetura de software
Arquitetura de software envolve decisões significativas sobre a organização do software incluindo a seleção de elementos estruturais e suas interfaces. Também envolve funcionalidade, usabilidade, resiliência (o quanto a aplicação é flexível), desempenho, capacidade de reuso dos componentes, compreensibilidade, limitadores econômicos e tecnológicos, conceitos estéticos e de mercado.
O risco de uma arquitetura mal elaborada pode tornar o software instável e incapaz de suportar requisitos existentes ou futuros do negócio para o qual é desenvolvido ou ainda, difícil de implantar ou gerenciar no ambiente de produção. Arquitetura cuida de como os principais elementos dentro do software são interligados.
Eis algumas das questões que a arquitetura do software leva em consideração:
• Como os usuários usarão a aplicação? Todos usarão o mesmo conjunto de hardware + software?
• Como a aplicação será implantada e gerenciada no ambiente de produção?
• Qual o nível de qualidade requerido pela aplicação quanto aos itens como: segurança, desempenho, concorrência, internacionalização e configuração?
• Como a aplicação pode ser desenvolvida para ser flexível e possa ser mantida ao longo do tempo?
• Quais são as tendências da arquitetura que poderão causar impacto na aplicação atualmente ou após ela ter sido implantada?
Com estes itens em mente já é possível começar a delinear como a aplicação deve ser escrita. Para auxiliar, alguns dos princípios da arquitetura também permitem estabelecer os padrões:
• Construa preparando para mudança em vez de desenvolver para manter como foi feito.
• Faça modelagem para analisar e reduzir riscos. A modelagem ajuda principalmente em casos onde existirá a possibilidade de usar vários meios para se gravar os dados. Ao se definir os nomes das colunas e os tipos de dados, já se começa a verificar limitações e riscos que poderão ser encontrados.
• Use os modelos e visualizações como ferramentas para comunicação e colaboração.
• Identifique as principais decisões de engenharia a serem tomadas.
Arquitetura é focada em organizar os componentes para suportar uma funcionalidade específica. Se estiver sendo escrita uma classe para armazenar dados, é isto o que a mesma deve fazer e somente isto. A classe não deve e nem precisa saber como estes dados são recuperados ou persistidos no disco, na rede ou mesmo na nuvem.
Durante esta fase é que pode se identificar se vai se desenvolver os componentes necessários internamente ou se serão adquiridos de terceiros. Em alguns casos, isto pode gerar uma grande economia de tempo e dinheiro.
Para os que estão envolvidos com o design, alguns princípios desta área podem ajudar a organizar o trabalho possibilitando benefícios como diminuição de custos – através de um desenvolvimento mais ágil – e promoção da usabilidade do software:
• Separação de responsabilidades. Para promover um baixo acoplamento, cada parte deve fazer o mínimo possível.
• Princípio da responsabilidade por um único aspecto. Cada componente deve ser responsável unicamente por uma funcionalidade ou característica específica ou agregação ou funcionalidade coesa.
"
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da .net Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
19 COMENTÁRIOS
Guilherme Gomes Do Braz
Parabéns Vladimir.
É o tipo de artigo, Arquitetura, que deveria figurar todo mês na Revista.
Você diz em seu artigo que "uso do LINQ poderia ser mais interessante"
Pode Dar um Exemplo?
É o tipo de artigo, Arquitetura, que deveria figurar todo mês na Revista.
Você diz em seu artigo que "uso do LINQ poderia ser mais interessante"
Pode Dar um Exemplo?
[há +1 ano] -
Responder
[autor]
Vladimir Rech
Olá Guilherme,
Desculpe pela demora, houve problemas aqui com o site.
Obrigado pelo retorno.
Quando digo que o uso do LINQ poderia ser mais interessante é por causa de toda a estrutura e as classes que o framework 3.5 possui.
Além das consultas LINQ que são mais integradas com a linguagem C#, cito como vantagem o mapeamento das tabelas do banco em classes via Entity Data Model.
Por este motivo considero o LINQ interessante.
Desculpe pela demora, houve problemas aqui com o site.
Obrigado pelo retorno.
Quando digo que o uso do LINQ poderia ser mais interessante é por causa de toda a estrutura e as classes que o framework 3.5 possui.
Além das consultas LINQ que são mais integradas com a linguagem C#, cito como vantagem o mapeamento das tabelas do banco em classes via Entity Data Model.
Por este motivo considero o LINQ interessante.
[há +1 ano] -
Responder
Leandro São Leandro
Gostaria de saber, tenho um projeto na empresa e vamos refazer o sistema, portanto, iremos usar design patterns, ainda não montei as camadas, mas a dúvida é utilizar o entity framework da versão do framework 4.0 ou utilizar a biblioteca Enterprise Library para acessar ao banco para fazer uma classe de consulta, exclusão, insert e update dos dados ?
[há +1 ano] -
Responder
[autor]
Vladimir Rech
Obrigado pelo feedback.
Quanto a arquitetura, considere os seguintes pontos:
=> Entity framework ainda está em desenvolvimento, verifique a documentação sobre a matureidade do código e se haverá alguma mudança. Por exemplo, na empresa onde trabalho, estamos apenas pesquisando esta tecnologia.
=> Enterprise library, por sua vez, está há mais tempo no mercado e já é mais maduro.
=> Considere o conhecimento do time de desenvolvimento. Todos precisam ter pelo menos um nível mínimo de conhecimento.
=> Qual o cenário de implantação do novo projeto e os requisitos. Tem coisas que ficam um pouco mais complicadas de se fazer com EF. Isto pode trazer impacto no prazo de entrega.
Espero ter ajudado...
Quanto a arquitetura, considere os seguintes pontos:
=> Entity framework ainda está em desenvolvimento, verifique a documentação sobre a matureidade do código e se haverá alguma mudança. Por exemplo, na empresa onde trabalho, estamos apenas pesquisando esta tecnologia.
=> Enterprise library, por sua vez, está há mais tempo no mercado e já é mais maduro.
=> Considere o conhecimento do time de desenvolvimento. Todos precisam ter pelo menos um nível mínimo de conhecimento.
=> Qual o cenário de implantação do novo projeto e os requisitos. Tem coisas que ficam um pouco mais complicadas de se fazer com EF. Isto pode trazer impacto no prazo de entrega.
Espero ter ajudado...
[há +1 ano] -
Responder
Nilson Carvalho De Souza
Caro Vladimir, boa noite.
Parabéns pelo artigo. Não é necessário enfatizar que é muito útil no dia-a-dia de nosso trabalho, como desenvolvedores.
Além disso, confirma o que outros artigos de outros autores nos orientam, quanto ao uso de camadas nos projetos, além da excelente didática.
Gostaria de perguntar sobre a possibilidade de compilar as DLL's dos projetos gerando um único executável. Por exemplo, digamos que eu tenha várias "Class Libraries" (DTO, DAL, BLL) em uma solução que representam as camadas em uma aplicação Windows Forms, cujo projeto principal tenha o nome: GRH.
Normalmente, teremos o GRH.exe e as DLL's DTO, DAL e BLL.dll. Como faria para incluir as DLL's e gerar somente o GRH.exe.
Note que não estou questionando sobre a eficácia desse tipo de abordagem, mas no detalhe técnico de como fazê-lo.
Obrigado.
Parabéns pelo artigo. Não é necessário enfatizar que é muito útil no dia-a-dia de nosso trabalho, como desenvolvedores.
Além disso, confirma o que outros artigos de outros autores nos orientam, quanto ao uso de camadas nos projetos, além da excelente didática.
Gostaria de perguntar sobre a possibilidade de compilar as DLL's dos projetos gerando um único executável. Por exemplo, digamos que eu tenha várias "Class Libraries" (DTO, DAL, BLL) em uma solução que representam as camadas em uma aplicação Windows Forms, cujo projeto principal tenha o nome: GRH.
Normalmente, teremos o GRH.exe e as DLL's DTO, DAL e BLL.dll. Como faria para incluir as DLL's e gerar somente o GRH.exe.
Note que não estou questionando sobre a eficácia desse tipo de abordagem, mas no detalhe técnico de como fazê-lo.
Obrigado.
[há +1 ano] -
Responder
André Gil
Bom dia,
Ótimo artigo, muito bem explicado.
Gostaria de saber se tem disponível em algum lugar os arquivos do projeto?
Obrigado.
Ótimo artigo, muito bem explicado.
Gostaria de saber se tem disponível em algum lugar os arquivos do projeto?
Obrigado.
[há +1 ano] -
Responder
[autor]
Vladimir Rech
Bom dia, André,
Obrigado pelo apoio.
Vou verificar junto à editora. Geralmente a revista possui um link para este conteúdo.
Obrigado pelo apoio.
Vou verificar junto à editora. Geralmente a revista possui um link para este conteúdo.
[há +1 ano] -
Responder
André Gil
Wladimir,
Obrigado pelo retorno rápido.
Acessei o link da edição e tem outras soluções, menos a do seu artigo, que mais me interessou.
Estou estudando a melhor forma de arquitetura para aplicações .NET e gostaria de analisá-la melhor.
Abraços!
Obrigado pelo retorno rápido.
Acessei o link da edição e tem outras soluções, menos a do seu artigo, que mais me interessou.
Estou estudando a melhor forma de arquitetura para aplicações .NET e gostaria de analisá-la melhor.
Abraços!
[há +1 ano] -
Responder
José Carlos Fialho
e então existe algum meio de fazer o download dos arquivos do projeto?
[há +1 ano] -
Responder
Nilson Carvalho De Souza
Para fazer o download dos arquivos do artigo:
1 - No item Menu (canto superior esquerdo), escolha "Central de arquivos da .net Magazine";
2 - Na tela que é aberta, é destacada a revista que está sendo lida. Clique no link "Clique aqui para acessar os arquivos";
3 - Na nova tela aberta, logo abaixo dos links de feedback, clique em "download".
Um abraço.
1 - No item Menu (canto superior esquerdo), escolha "Central de arquivos da .net Magazine";
2 - Na tela que é aberta, é destacada a revista que está sendo lida. Clique no link "Clique aqui para acessar os arquivos";
3 - Na nova tela aberta, logo abaixo dos links de feedback, clique em "download".
Um abraço.
[há +1 ano] -
Responder
Devmedia - Equipe De Moderacao
Pessoal, no link a seguir, vocês encontrarão os arquivos dessa edição:
http://www.devmedia.com.br/articles/viewcomp.asp?comp=20207
Atenciosamente,
Equipe Devmedia.
http://www.devmedia.com.br/articles/viewcomp.asp?comp=20207
Atenciosamente,
Equipe Devmedia.
[há +1 ano] -
Responder
Bruno José Da Costa
Neste link não tem o projeto feito neste artigo.
[há +1 mês] -
Responder
Devmedia - Equipe De Moderacao
Bruno, no link acima se encontra o código dessa revista.
Atenciosamente,
Equipe devmedia.
Atenciosamente,
Equipe devmedia.
[há +1 mês] -
Responder
Bruno José Da Costa
Vladimir, não entendi a seguinte parte:
Para editar os dados e vincular o formulário com a classe Contato será necessário criar uma instância da mesma. Isto pode ser feito declarando uma variável dentro da classe do formulário logo após a inicialização do mesmo, no seu construtor.
Desculpe, mas não sei onde declarar a variável.
Obrigado.
Para editar os dados e vincular o formulário com a classe Contato será necessário criar uma instância da mesma. Isto pode ser feito declarando uma variável dentro da classe do formulário logo após a inicialização do mesmo, no seu construtor.
Desculpe, mas não sei onde declarar a variável.
Obrigado.
[há +1 mês] -
Responder
Bruno José Da Costa
Minhas referencias também, não estão fucionando corretamente.
Ex: Na pasta referencias Aparecem;
Contato
Contato.DB
Porém, para usar o Contato.DB, tenho que colocar
Contato.Banco.SqlServer.Incluir oIncluir.
E ao chamar o objeto oIncluir.(Método), não aparece o método incluir.
Ex: Na pasta referencias Aparecem;
Contato
Contato.DB
Porém, para usar o Contato.DB, tenho que colocar
Contato.Banco.SqlServer.Incluir oIncluir.
E ao chamar o objeto oIncluir.(Método), não aparece o método incluir.
[há +1 mês] -
Responder
[autor]
Vladimir Rech
Olá Bruno, obrigado pelo feedbak.
A declaração deve ser feita logo abaixo da declaração da classe do formulário.
Abra o formulário, exiba o código e abaixo da declaração da classe do formulário, coloque a declaração da classe contato.
Espero ter ajudado.
A declaração deve ser feita logo abaixo da declaração da classe do formulário.
Abra o formulário, exiba o código e abaixo da declaração da classe do formulário, coloque a declaração da classe contato.
Espero ter ajudado.
[há +1 mês] -
Responder
Bruno José Da Costa
Obrigado.
Deu certo.
Deu certo.
[há +1 mês] -
Responder
Maxuel De S Lessa
Olá a todos, alguém consiguiu baixar os fontes desse projeto?
No que eu fiz não tem esse projeto.
Com qual nome ele vem no download?
No que eu fiz não tem esse projeto.
Com qual nome ele vem no download?
[há +1 mês] -
Responder
Devmedia - Equipe De Moderacao
Maxuel, para baixar os fontes dessa edição, é necessário ir na página principal dessa edição e clicar na opção "código-fonte".
[há +1 mês] -
Responder
Você está em:
canal .net
Publicidade
Vladimir Rech
Space do autor
Formado em Tecnologia em desenvolvimento de software pela UTF/PR.
Desenvolvedor de software.
Palestrante.
Space do autor
1
0
