mysql - É viável mudar de banco de dados em um sistema já existente? - Stack Overflow em Português
Estou iniciando um projeto em ASP.NET MVC 5 com Entity Framework para um cliente, onde o mesmo optou por utilizar um banco de dados gratuito, no caso o MySQL. Porém, com o crescimento da aplicação, prevejo a melhor utilização de um banco de dados como o SQL Server.
Minha sugestão é utilizar o SQL Server desde o inicio, no entanto, meu querido cliente diz "Vamos iniciar com MySQL, qualquer coisa mudamos depois".
Quando na faculdade, vários professores diziam que isso era possível, e em projetos onde separamos as camadas e responsabilidades era ainda menos doloroso de realizar. Portanto, nunca fiz e nem tenho ideia, em um projeto asp.net mvc, como devo proceder com isso?
Queria saber qual seria o retrabalho, pensando a nível de CRUD, caso eu utilize Controller's e View's gerada utilizando scaffold, onde estes utilizam diretamente o meu contexto, inicial em MySQL, quando eu alterar o banco de dados da aplicação para SQL Server, quais seriam os riscos e retrabalho?
editada 5/09/14 às 20:29
perguntada 5/09/14 às 14:03
Na verdade só pelo fato de ser MVC, se for realmente MVC é tranquilo, pois a estrutura já é preparada para isso. – Alex Schmitt 5/09/14 às 16:50
Nunca trabalhei com ASP. Ele possui um ORM? Neste caso a abstração do ORM ajudaria muito, nem seria tento a questão do MVC. – user7261 5/09/14 às 16:55
@Andrey Possui vários. O Entity Framework é um deles. – Leonel Sanches da Silva 5/09/14 às 22:55
Respondendo no ponto de vista da tecnologia:
Nenhum. Exceto que você teria que apenas instalar e reconfigurar os provedores de dados.
O Entity Framework foi pensado para ser agnóstico. Agnóstico quer dizer que ele não implementa qualquer particularidade tecnológica de um banco de dados específico. A sintaxe e a maneira de trabalhar com ele são sempre as mesmas.
A única coisa que pode gerar retrabalho é se você resolver usar SQL juntamente com a lógica tradicional do Entity Framework, essencialmente se houver algum elemento da sintaxe que é particular de um determinado fornecedor de banco de dados.
No MySQL você configuraria o provedor de dados em seu Web.config mais ou menos assim:
Enquanto que no SQL Server, a configuração seria assim:
respondida 5/09/14 às 21:31
obrigado pela ajuda, e deixa eu ver se entendi bem, eu usando o ORM, Entity Framework, e não utilizar SQL junto ao mesmo, basicamente eu necessito somente alterar o provedor de dados do meu webconfig? – Erico Souza 5/09/14 às 22:55
@EricoSouza Correto. – Leonel Sanches da Silva 5/09/14 às 22:55
Cara, obrigado. – Erico Souza 5/09/14 às 23:00
Portanto, nunca fiz e nem tenho ideia, em um projeto asp.net mvc, como devo proceder com isso?
Se você ainda não desenvolveu um projeto em Asp.net MVC esse aqui introduz o conceito e possui algumas referências para te ajudar.
...caso eu utilize Controller's e View's gerada utilizando scaffold, onde estes utilizam diretamente o meu contexto, inicial em Mysql...
Utilizando diretamente seu contexto você ficará amarrado a tecnologia, pois em todo ponto do código onde você tem referência a essa tecnologia você precisaria mudar. Dependendo da sua implementação é um retrabalho bem árduo, além de correr risco de duplicidade de código e ter maior dificuldade para testes da sua aplicação.
Usando acesso direto com NHibernate para recuperar dados no Controller eu ficaria com referências como NHibernate, NHibernate.Linq, além de objetos específicos da tecnologia NHibernate como ISession, etc.
using NHibernate; //Código relacionado a tecnologia de acesso a BD
using NHibernate.Linq; //Código relacionado a tecnologia de acesso a BD
//Você provavelmente iria duplicar código como esse em outros Controllers
//gerando possíveis retrabalhos
var empregados = session.Query<Empregado>().ToList();
return View(empregados);
Uma alternativa é utilizar o padrão de projeto Repository, ele centraliza seu código de acesso ao banco de dados (inserção, atualização, exclusão e recuperação de dados), adicionando uma camada de separação de forma que ao mudar a tecnologia de acesso a dados, você altera apenas uma camada da sua aplicação com um retrabalho bem pequeno comparado a questão de usar diretamente o contexto.
Dado o exemplo, da mesma forma, usando diretamente tecnologias específicas de acesso a dados no seus Controllers, seja Entity Framework, MySql, X, Y, etc... você ficaria com referências e códigos que geram retrabalho caso você mude a tecnologia.
Em suma, em vez de criar um projeto Asp.net MVC e desenvolver sua aplicação, seria interessante você criar pelo menos mais um projeto na sua solução para centralizar seu código de acesso ao banco de dados, isolando os objetos de domínio (relacionados ao negócio) de detalhes do código de acesso.
respondida 5/09/14 às 14:39
"Utilizando diretamente seu contexto você ficará amarrado a tecnologia". Discordo fortemente disso. O contexto já é algo agnóstico por definição. A única amarra tecnológica são connection strings. Passar a aplicação para o design de repositórios é facultativo. – Leonel Sanches da Silva 5/09/14 às 17:14
@CiganoMorrisonMendez valeu, pelo seu comentário percebi que não foi clara a resposta e atualizei. – Renan 5/09/14 às 21:24
@Renan obrigado pela resposta, de início vou estudar a respeito do desgin de repositório também. Gostei da questão de eu ter um projeto na mesma Solution apenas para acesso ao BD. Obrigado também pela referência do projeto MVC. Você também mencionou o contexto, e conforme o exemplo que você postou, mesmo que eu mude de banco de dados, de mysql para sqlserver ou oracle, por exemplo, o ORM (nhibernate ou ef) continuará operando da mesma maneira, correto? – Erico Souza 5/09/14 às 23:00
@EricoSouza o exemplo de código que inseri foi para mostrar que ficaria ruim a manutenção do seu código usando tecnologias de acesso a dados diretamente nos seus Controllers. Uma alternativa é isolar isso em um outro projeto por exemplo usando Repository, para não precisar mudar o código em um monte de lugar caso mude de tecnologia. Aí você pode alterar a tecnologia no futuro e as demais camadas da sua aplicação continuarão operando da mesma maneira. – Renan 8/09/14 às 12:56
O problema é que você terá retrabalho caso esteja trabalhando com linguagem nativa do banco, caso use algum framework para trabalhar encima da camada da entidade em seu código, o trabalho que você terá será na configuração somente, porque todas as suas manipulações no banco de dados estarão mapeadas através de suas entidades, um exemplo é usar o QueryDSL, todas as suas manipulações são feitas através das suas entidades.
public List<Sale> findSalesByPrice() {
QSale sale = QSale.sale;
return new JPAQueryFactory(entityManager)
.selectFrom(sale)
.where(sale.price.eq(20))
select * from sale where price = 20;
respondida 24/04/19 às 20:43
Marcelo Lubanco ThoméMarcelo Lubanco Thomé
Esta não é a resposta que você está procurando? Pesquise outras perguntas com a tag mysql asp.net-mvc entity-framework arquitetura-de-software ou faça sua própria pergunta.