APLICA?ÃO FLEXIVEL
Geralmente não crio tópicos em foruns, apesar de le-los e sempre responder as questões que sei.
mas me apareceu uma dúvida sobre modelos de acesso a dados e Design patterns ( MVC mais propriamente )
Em qual design patterns ou Estrutura de acesso a dados é possivel fazer uma aplicação se conectar com variados tipos de banco de dados sem que precise alterar nenhum ou quase nenhum código na aplicação?
Exemplo: Vamos supor que temos uma aplicação em um cliente criada com o acesso a um MySql e um outro cliente quer o mesmo aplicativo em oracle ou Sql Server
o que fazer nesse caso? 3 camadas? Reescrever todo acesso? usar dbcommand, dbadapter etc?
ja vi algo feito em NHibernate, mas caso tenham soluções em ADO usando as classes citadas anteriormente seria de melhor valia pra estudos
outra questão, seria possivel ao menos [Ô]simular[Ô] um padrão MVC em aplicações desktop?
Obrigado ;)
http://www.macoratti.net/11/10/net_pr1.htm
E dê uma olhada nisso aqui também:
http://www.macoratti.net/12/04/c_dbind.htm
Citação:http://www.macoratti.net/12/04/c_dbind.htm
Bem interessante essa ProviderFactory..
Citação:
outra questão, seria possivel ao menos [Ô]simular[Ô] um padrão MVC em aplicações desktop?
Na verdade você pode desenvolver um projeto Desktop, Console, Web utilizando os padrões MVC basta respeitar suas regras e o padrão..
Só muda no caso da View de Web é um .jsp (java), .html, .aspx. eu penso que no caso a [Ô]View[Ô] em desktop seria os Forms, eaà tem a Model e a Controller
normalmente..
Eu penso assim hehe.. o bom do MVC é que você pode ter 4 projetos: desktop, web, console e mobile você consegue reaproveitar a Model e a Controller para esses mesmos
3 projetos única coisa que muda são as Views..
Caso estiver errado alguém por favor me corrija!
Abraços!
Mestre
eu pensei realmente nisso. Mas talvez dependendo da aplicação não seria atraente a tentativa de um MVC no win forms. Na verdade não consigo gostar do MVC apesar de ser bastante útil, porém se a aplicação ir crescendo desenfreadamente e sem uma boa documentação, fica muito facil esquecer algo da model ou do controller
sobre o IDbCommand.
verifiquei que ele não aceita uma instancia dele (obvio que não aceitaria), então criei o parametro a mão e retornem um Parameter.Name = [Ô]@nome[Ô];
a duvida é:
como associo esse parametro um textbox? (@nome,textbox.Text) não funciona..
Citação:Na verdade não consigo gostar do MVC apesar de ser bastante útil, porém se a aplicação ir crescendo desenfreadamente e sem uma boa documentação, fica muito facil esquecer algo da model ou do controller
A ideia principal do MVC é separar as responsabilidades do sistema da forma mais consistente e clara possÃvel, por isso a ideia de um Model, View e um Controller. Afinal, o Controller está ali apenas para direcionar o fluxo da aplicação e o Model para gerenciar sua lógica de negócio, por isso que não vejo muito sentido quando o colega diz que fica fácil de esquecer algo quando o assumimos. Na verdade, esse fluxo irá acontecer em todos os cenários, seja no WebForm, MVC, etc, e o que o MVC faz é centralizar isso em um lugar pra justamente facilitar o seu entendimento e tornar mais fácil sua manutenção.
Citação:Em qual design patterns ou Estrutura de acesso a dados é possivel fazer uma aplicação se conectar com variados tipos de banco de dados sem que precise alterar nenhum ou quase nenhum código na aplicação?
Exemplo: Vamos supor que temos uma aplicação em um cliente criada com o acesso a um MySql e um outro cliente quer o mesmo aplicativo em oracle ou Sql Server
o que fazer nesse caso? 3 camadas? Reescrever todo acesso? usar dbcommand, dbadapter etc?
Vou fugir um pouquinho do assunto do tópico.
Vamos falar da parte comercial do negocio.
Se tal cliente já possuà um banco de dados(com licença e tudo mais) então acho correto você aplicar um conceito em seu sistema que o fará trabalhar com o banco do cliente .
No entanto, acredito que teu sistema deve ter uma identidade própria e não ser um coadjuvante.
Partindo desse princÃpio, saiba que terás que reescrever boa parte do código ([Ô]SQL[Ô]) e considerar X para Y no que diz respeito a manipulação de dados.
Tendo em vista que os SGBDs não seguem um padrão internacional de comandos, cabe ressaltar que um simples select pode mudar de banco para banco caso você utilize funções especÃficas na linha de comando.
Exemplificando seria algo assim :
Concatenação entre MySQL e SQL Server/Access :
Exemplo de concatenação no Mysql:
SELECT concat(sNome, [ô] Pontos/Total [ô], nPontos, [ô]/[ô], nTotal
FROM apostas
Exemplo de concatenação em SQL Server ou Access
SELECT Snome + [ô] Pontos/Total [ô] + nPontos + [ô]/[ô] + nTotal
FROM apostas
Outro exemplo simples porém diferente entre os bancos :
Limitar o nº de linhas em uma consulta
Em SQL Server e Access use o Top para indicar o limite de linhas desejado na consulta.
SELECT top 7 * FROM produtos
Em Mysql use o Limit para indicar o limite de linhas desejado na consulta.
SELECT * FROM produtos limit 0,7
Estes são apenas dois exemplos comuns que notoriamente são diferentes entre estes bancos.
Existem muitas funções em cada um deles que são completamente diferente tratados entre si.
Além desses [Ô]problemas[Ô], existem ainda as PROCEDURES, TRIGGERS , VIEWS .....
Então minha dica é : Ofereça um serviço completo onde o teu sistema é quem definirá qual banco o seu cliente utilizará.
Dados xml, csv, mysql, sql server... independentemente da fonte de dados, roda tudo.
Existem outros trabalhos que fazem isso, apesar de algumas limitações, como o NHibernate.
Existe um padrão no .NET com nomenclatura e namespaces na parte do system.Data.
SQLDataAdapter, SqlCommand.. etc, tudo a mesma coisa. Só muda se você está usando SQL Server, MySQL... que vai mudar só o namespace e ligeiramente o nome dos objetos. Mas é praticamente a mesma coisa pra usar.
Infelizmente, como o Foxman disse, existem diferenças de sÃntese. AÃ começa a ficar chato. Se for fazer na unha, dá um trabalho ...
Abraços!
requer um certo [Ô]esforço[Ô] por parte dos colaboradores. Por isso imaginei esse cenario de escabilidade + design patterns.
sobre os SQL sim, conheço as diferenças porém nesse caso eu pensei em um mapeamento de dados o que por si só ja seria complexo de fazer.
Ainda estou pensando sobre esse cenário ( é somente estudos ) no momento estou vendo o MVC direto no windows forms e olhando a possibilidade de um mapeamento de dados em que eu leia esses dados e faça seu escalonamento em memória e depois jogue pra um xml qualquer e passe a ler direto do xml atribuindo isso em variaveis
Obrigado pessoal
só que eu não posso virar as costas para todo tipo de possibilidade aparente. A questão de MVC em ASP.NET eu domino, o conceito la é bem mais facil pois ja vem também boa parte criada. Em Windows form to fazendo agora pois sempre usei Camadas classicas ou MVP ou mesmo quando dependendo da aplicação código direto no objeto ( orientado a eventos ) a que eu prefiro
Dê uma olhada neste tópico http://www.vbmania.com.br/index.php?modulo=forum&metodo=abrir&id=448971&pagina=1, talvez ele possa te ajudar.