ASP.NET MVC standart e migração para NET CORE

[JPgod]

Boas

Atualmente na empresa onde trabalho tem um projecto ASP.NET MVC 5, com EF6 Code First.

Quando cheguei, a Solution só tinha um projecto, ou seja não era uma aplicacão multi camadas, mas a complexidade foi aumentando e comecei a separar por camadas:

- Criei uma "Data Layer", separando do projecto MVC os DBcontexts, Models, Mappings e classes auxiliares) para um projecto separado. Foi difícil, mas deu certo, ainda mais que uso 2 contextos, um de SQL Server e um MYSQL.
- Foi criado um Windows Service e mais uma console app de "Sockets", daí essencial ter uma camada de dados separada e referenciar só o projecto do Data Layer.

Entretanto tem mais desafios e necessidades:
- Dentro do projecto MVC tem uma Web API incorporada, que é uma parte crítica, dado que comunica com routers 4G e surgiu a necessidade urgente de separar a API num projecto independente, de forma até facilitar alterações e deploys e não ter que parar o projecto Web ou criar bugs. Assim pode-se fazer ajustes, criar novas APIS e não ter que carregar o site todo ás costas.

- A empresa quer cortar custos, junto com o pessoal aqui ser "Linux users", logo é preciso reduzir a dependência do Windows, a começar no futuro deixar de usar SQL SERVER e usar uma alternativa free como MariaDB, PostGreeSQL e afins. Atualmente usamos apenas o SQL SERVER Express, com limitações óbvias quando o projecto começar a escalar.

- Possibilidade de usar a API em Linux, de modo a reduzir custos com servidores Windows e usar Dockers e ter várias instancias para balanceamento.

Com isso e depois de alguma pesquisa, o NET CORE parece atender a isso tudo. Suporta Linux, Suporta Docker, portanto a ideia inicial era criar o projecto de API usando .Core, mas bati numa parede

- O Core tem muitas diferenças pro standart, especialmente configs e fiquei meio perdido.
- Não consigo integrar/referenciar o projecto do database layer, parece que só dá para usar EF CORE, tudo que encontro na web de guias e tutoriais e sempre com EF CORE.
- Migrar a database layer para EF CORE vai dar imensa reprogramação, especialmente os mappings que é uma estrutura BEM DIFERENTE. Um dos motivos de abrir a thread antes de perder horas nisso e depois não dar.
- Como fica o Windows Service e principalmente, o projecto Web? Dá para integrar o EF CORE ou terei que migrar para MVC CORE?
- O Windows Service também seria no futuro migrar para .CORE com suporte a docker, para igualmente rodar em Linux, no fundo o único servidor windows seria para o projecto MVC WEB.

No fundo seria tentar criar uma estrutura na solution do tipo

- WEB
- API
- DAL
- Windows Services e/ou docker services
- Helpers (não existe ainda)
- Unit Tests/console apps de testes

Que ajuda/dicas me dão? ou é melhor pensar em refazer tudo do zero já 100% CORE a longo prazo e migrar as APIS para um projecto Web Api padrão a curto prazo?

 

[d@niel]

Boas.

Normalmente o problema pode é ser o uso de componentes de terceiros, que não tenham suporte para .Net Core (como falas de uma DLL de um banco).

Se não é esse o caso ou se esses componentes têm uma versão compatível com .Net Core, era avançar com um projecto de teste onde todas essas peças (Web, API e Serviços [Daemons]) estejam incluídas.

Com isto, é validar se conseguem ter uma independência total do Windows e do SQL Server, conseguindo alojar tudo em Linux (com ou sem Docker). O "WindowsService" em Linux, seria uma Console App em .Net Core, com umas configurações devem chegar ao mesmo comportamento de um Windows Service (vê se isto ajuda).

Eu só avançaria num trabalho desses, conseguindo validar que as coisas funcionam mesmo, senão ficam com a coisa a meio.

A nível de fases, depende de como as coisas estão feitas. O projecto Web só comunica com a API ou também vai ao DataLayer (por intermédio de referência de projectos)? Se é só com a API, então há potencial para fasear o trabalho.


Em jeito de resumo: O único problema que vejo, é mesmo a DLL do banco... que pode obrigar a manter Windows só para o Serviço.

 

[JPgod]

A "DLL do banco" é na verdade o projecto de data layer, que é o projecto onde está o contexto de base de dados (2 contextos, um sql server e um mysql) models, migrations e mappings.

Numa fase inicial vou optar por Web Api 2 normal e futuramente migrar tudo para .NET CORE.

Penso que de momento não tenho problemas de componentes DLL de terceiros, porque ou uso o que está no framework ou via NUGET.

A nível de fases, depende de como as coisas estão feitas. O projecto Web só comunica com a API ou também vai ao DataLayer (por intermédio de referência de projectos)? Se é só com a API, então há potencial para fasear o trabalho.

A ideia é o projecto Web só comunicar com o datalayer, a API é para acesso externo (comunicação M2M entre routers e o sistema)

 

[hferreira.80]

Em relação ao motor do SQL Server, desde a última versão (2017), que existe suporte nativo para Linux, em qualquer uma das edições e não e apenas um port manhoso.
Em relação ao Management Studio do SQL Server penso que tenha os dias contadas e existe um novo gestor cada vez melhor da Microsoft e multi-plataforma.

Em relação ao .NET Core, existem imensas diferenças em comparação com o .NET Framework.
A começar pelo EF6 que agora se chama EF Core.
O EF morreu na versão 6 e não vai ter novos desenvolvimentos, no entanto vai poder funcionar em cima do .NET Core 3 mas só para Windows, logo está fora de questão para ti.
Migrar tudo de uma vez é uma péssima ideia, assim, a forma é fazer por blocos, manter no .NET Framework e testar em ambos os runtimes.
Por exemplo começar-se com o EF Core que apesar do nome, corre tanto no runtime .NET Core como .NET Framework.
Assim o melhor é portar este, tratar de todos os bugs que vão surgir e quando estiver estável, saltar para o próximo bloco.

Eu já consegui fazer isto num projeto de alguma dimensão.
Apesar do código ainda correr no .NET Framework é 100% compatível com o .NET Core e basta só mudar o interruptor.

Porquê que ainda não foi feito ?
.NET Core por trás do IIS (ou melhor por trás de qualquer servidor web) não vale nada, pois a performance cai de 4 a 5 vezes e isso até já foi admitido pela própria Microsoft.
Supostamente o .NET Core 2.2 que deve saír até ao final do ano ver corrigir isto no IIS apenas, ou seja, se a ideia é usar por exemplo Apache, vão ter uma aplicação com performance da década passada.
A alternativa é usar o Kestrel diretamente no entanto tem imensas limitações para além de que a segurança não é o target.

Existem imensos detalhes e desafios que te vais deparar para conseguir migrar e é algo que não se faça do dia para a noite.
Até cheguei a fazer código compatível com ambos os runtimes que ainda não existe no .NET Core.
Mais questão, podes mandar MP.

 

[JPgod]

Que gestor é esse que vai subistituir o SSMS?

De qualquer forma a parte do SQL SERVER não é crítica, porque como disse, a ideia e usar outro SDBD.

Isso da performance é que não, Já tive/tenho problemas de performance... Ee calhar é cedo demais para pensar numa empreitada destas de "all linux & .NET CORE"...

Mas se conseguir já migrar o banco para outro que não o SQL SERVER já elimina uma VM Windows e por fim a licença do próprio Sql Server Enterprise.

Em principio, posso pegar outro SGBD, configurar o EF, roda o migration, migrar os dados e programação (SPs, Views e Functions) e já está?

 

[hferreira.80]

Que gestor é esse que vai subistituir o SSMS?
> Azure Data Studio cuja versão final 1.0 saiu há muito pouco tempo (em preview era conhecido como SQL Operations Studio): https://docs.microsoft.com/en-us/sql/azure-data-studio/what-is?view=sql-server-2017

Funciona em Windows, macOS e Linux. De momento NÃO subtitui tudo o que o SSMS mas já subsitui em muitas funcionalidades e até tem novas funcionalidades a cada atualização mensal, inclusivé pequenas features que o SSMS provavelmente nunca virá a ter.
Eles não escondem que o ADS NÃO subsitui o SSMS mas também dão a entender que é esse o objetivo a longo prazo. O SSMS teve muitos anos de desenvolvimento.

Uso o ADS diariamente sem ter de recorrer mais ao SSMS (já está neste ponto de qualidade).

Ee calhar é cedo demais para pensar numa empreitada destas de "all linux & .NET CORE"...
> Desde que saiu o .NET Core 1.0, tenho acompanhada e só na versão 2.1 é que considerei ter o mínimo dos mínimos para se começar a testar uma migração por N factores que agora não interessam para o caso. No entanto a performance é horrível.
Vamos ver se a 2.2 RTM cumpre o mínimo de iguar o .NET 4.X por trás do IIS. No mínimo tem de ser igual.
Seja como for ainda é um runtime jovem e concerteza que irá melhorar ao longo das versões mas não deixa de marcar o .NET Framework como legacy.

Mas se conseguir já migrar o banco para outro que não o SQL SERVER já elimina uma VM Windows e por fim a licença do próprio Sql Server Enterprise.
> Como referir, a partir do SQL 2017, a questão do Windows já nao se coloca e portanto isso não é razão.
A questão da licença, até 10 GB também não. Acima disso sim mas se calhar estamos a falar em algum que tem condições para se adquirir uma licença no entanto tal como o Office 365, pode-se alugar o SQL por um valor residual e com acesso sempre à última versão.
Mas a opção de mudar também é válida (para mim hoje em dia não por essas razões mas cada cabeça, sua sentença).

Em principio, posso pegar outro SGBD, configurar o EF, roda o migration, migrar os dados e programação (SPs, Views e Functions) e já está?
> Sim. Passar das palavras à ação dá mais trabalho e demora sempre mais tempo do que o estimado.
Já usei diversos motores de BD e para mim o SQL Server continua a ser o de eleição mas há outros igualmente válidos.

 

[JPgod]

> Azure Data Studio cuja versão final 1.0 saiu há muito pouco tempo (em preview era conhecido como SQL Operations Studio): https://docs.microsoft.com/en-us/sql/azure-data-studio/what-is?view=sql-server-2017

Funciona em Windows, macOS e Linux. De momento NÃO subtitui tudo o que o SSMS mas já subsitui em muitas funcionalidades e até tem novas funcionalidades a cada atualização mensal, inclusivé pequenas features que o SSMS provavelmente nunca virá a ter.
Eles não escondem que o ADS NÃO subsitui o SSMS mas também dão a entender que é esse o objetivo a longo prazo. O SSMS teve muitos anos de desenvolvimento.

Uso o ADS diariamente sem ter de recorrer mais ao SSMS (já está neste ponto de qualidade).

Ok, vou experimentar o ADS. Portanto consigo fazer na boa as querys, gerir a BD? pode enunciar que coisas o ADS faz e o SSMS não e vice versa?

> Desde que saiu o .NET Core 1.0, tenho acompanhada e só na versão 2.1 é que considerei ter o mínimo dos mínimos para se começar a testar uma migração por N factores que agora não interessam para o caso. No entanto a performance é horrível.
Vamos ver se a 2.2 RTM cumpre o mínimo de iguar o .NET 4.X por trás do IIS. No mínimo tem de ser igual.
Seja como for ainda é um runtime jovem e concerteza que irá melhorar ao longo das versões mas não deixa de marcar o .NET Framework como legacy.

Pois, acredito que o .Core vai substituir tudo, mas talvez melhor deixar para coisas novas...

> Como referir, a partir do SQL 2017, a questão do Windows já nao se coloca e portanto isso não é razão.
A questão da licença, até 10 GB também não. Acima disso sim mas se calhar estamos a falar em algum que tem condições para se adquirir uma licença no entanto tal como o Office 365, pode-se alugar o SQL por um valor residual e com acesso sempre à última versão.
Mas a opção de mudar também é válida (para mim hoje em dia não por essas razões mas cada cabeça, sua sentença).

A questão prende-se com o custo de usar uma instancia AWS com o SQL Server. Actuamente temos um t2.small que custa 0,044 US$ por hora. Com a licença Web vai para 0,144 US$, bem mais caro! Nem é tanto o custo do servidor Windows em si, mas o pacote completo.

A BD ainda não chegou a 2 GB e a maior parte é um log que pode-se purgar os dados antigos se for necessário.

Infelizmente é um projecto que praticamente nem dá dinheiro para pensar em algo mais robusto. Mesmo o servidor é apenas 1 core com 1 GB de ram, pense em algo lento...

> Sim. Passar das palavras à ação dá mais trabalho e demora sempre mais tempo do que o estimado.
Já usei diversos motores de BD e para mim o SQL Server continua a ser o de eleição mas há outros igualmente válidos.

Sim, deve ser bem mais difícil do que eu penso, mas a vantagem de usar ORM como o EF é fazer a junção entre os models e a BD sem preocupar qual o engine que corre por trás.

Claro que o facto de ainda ter coisas "old school" como SP, functions e views é o que pode dar mais problemas, mas tinha operações que era feito totalmente pelo EF, criava querys absurdas e com lentidão considerável e quando passou a processar no SQL usando views ou SP deu um boost de performance considerável.

 

[hferreira.80]

Ok, vou experimentar o ADS. Portanto consigo fazer na boa as querys, gerir a BD? pode enunciar que coisas o ADS faz e o SSMS não e vice versa?
> Numa rápida pesquisa: https://cloudblogs.microsoft.com/sqlserver/2018/09/25/azure-data-studio-for-sql-server
Mas sim, faz isso tudo. O que ainda não faz (eu pessoalmente dispenso) é por exemplo ver a estrutura de tabela num diagrama e poder adicionar campos dessa forma (eu faço por sql).

Pois, acredito que o .Core vai substituir tudo, mas talvez melhor deixar para coisas novas...
> Para coisas novas sem dúvida que iniciar no .NET Framework não faz sentido neste fase. Para coisas legacy apenas para manter, não faz sentido migrar para .NET Core. O .NET Framework a partir de agora irá se manter apenas em manutenção mas mesmo assim não irá desaparecer nos próximos 5 anos (provavelmente nem nos próximos 10 ou 15), pois existe mais de 1 milhão de aplicações que usam .NET Framework (segundo a MS). Para aplicações em pleno desenvolvimento/continuidade feitas em .NET Framework faz/pode fazer sentido migrar para .NET Core.

A questão prende-se com o custo de usar uma instancia AWS com o SQL Server. Actuamente temos um t2.small que custa 0,044 US$ por hora. Com a licença Web vai para 0,144 US$, bem mais caro! Nem é tanto o custo do servidor Windows em si, mas o pacote completo.
> Porque não uma instância sem SQL Server e depois instalar o SQL Express que dá até 10 GB ?

A BD ainda não chegou a 2 GB e a maior parte é um log que pode-se purgar os dados antigos se for necessário.
> O log consegue ser limitado a MB mantendo a BD sempre compacta !

Infelizmente é um projecto que praticamente nem dá dinheiro para pensar em algo mais robusto. Mesmo o servidor é apenas 1 core com 1 GB de ram, pense em algo lento...
> Para mim isso então nem seria de equacionar uma instância mas sim servidor partilhado !

Sim, deve ser bem mais difícil do que eu penso, mas a vantagem de usar ORM como o EF é fazer a junção entre os models e a BD sem preocupar qual o engine que corre por trás.
> Também uso EF (agora EF Core) no entanto falaste em SPs que podem ser complexas e ai estás fora do contexto do EF e podem ser complexas.

Claro que o facto de ainda ter coisas "old school" como SP, functions e views é o que pode dar mais problemas, mas tinha operações que era feito totalmente pelo EF, criava querys absurdas e com lentidão considerável e quando passou a processar no SQL usando views ou SP deu um boost de performance considerável.
> Sei do que falas.
Uso EF para 80 ou 90 % das operações e ADO direto para algumas operações em massa que com EF demoraria minutos e com ADO segundos ou instaneo mas ainda assim sempre a fugir de SPs e com SQL o mais standard possível para caso um dia necessite migrar de BD (é um suponhamos que provavelmente nunca vai acontecer).

 

[JPgod]

> Numa rápida pesquisa: https://cloudblogs.microsoft.com/sqlserver/2018/09/25/azure-data-studio-for-sql-server
Mas sim, faz isso tudo. O que ainda não faz (eu pessoalmente dispenso) é por exemplo ver a estrutura de tabela num diagrama e poder adicionar campos dessa forma (eu faço por sql).

Adicionar campos faço por SQL mesmo ou pelo C#, já que uso EF Code first e só rodar uma migration

> Para coisas novas sem dúvida que iniciar no .NET Framework não faz sentido neste fase. Para coisas legacy apenas para manter, não faz sentido migrar para .NET Core. O .NET Framework a partir de agora irá se manter apenas em manutenção mas mesmo assim não irá desaparecer nos próximos 5 anos (provavelmente nem nos próximos 10 ou 15), pois existe mais de 1 milhão de aplicações que usam .NET Framework (segundo a MS). Para aplicações em pleno desenvolvimento/continuidade feitas em .NET Framework faz/pode fazer sentido migrar para .NET Core.

Pois, é o que mais faz sentido. NET .Core para cenas novas e mantir o ASPNET 4.x pro resto.
Olha, estou aqui a criar um mini projecto Web API Core + Angular como parte de um recrutamento...

> Porque não uma instância sem SQL Server e depois instalar o SQL Express que dá até 10 GB ?

O servidor já existe configurado, por isso "deixar estar".

A BD ainda não chegou a 2 GB e a maior parte é um log que pode-se purgar os dados antigos se for necessário.
> O log consegue ser limitado a MB mantendo a BD sempre compacta !

Atenção é uma tabela de log gigantesca e não o ficheiro de "log" do SQL Server. Alem de já ter milhões de linhas, cada uma tem bastantes dados, mas não é algo crítico de momento que tenha que guarda dados 4ever.

> Para mim isso então nem seria de equacionar uma instância mas sim servidor partilhado !

Explica nesta situação... Como se sabe, instancias do AWS são maquinas virtuais... O que difere para outro alojamento com servidor partilhado? De momento até temos 3 instancias, uma de IIS, uma de SQL Server e uma terceira de Linux com Radius e MySQL

> Sei do que falas.
Uso EF para 80 ou 90 % das operações e ADO direto para algumas operações em massa que com EF demoraria minutos e com ADO segundos ou instaneo mas ainda assim sempre a fugir de SPs e com SQL o mais standard possível para caso um dia necessite migrar de BD (é um suponhamos que provavelmente nunca vai acontecer).

Eu por acaso não uso ADO. Uso apenas EF, a diferença que as Views estão mapeadas como Models, logo invoco como outro Model qualquer (só tem que impedir o migration de gerar a tabela) e as SPs rodo via ExecuteSqlCommand usando parâmetros quando necessário.

E é como dizes, a performance não tem nada haver. Tinha uma listagem que demorava vários segundos para aparecer e com um dataset de apenas 50 linhas e agora é instantaneo!

O chato serar mesmo isso de migração, mas como por enquanto são poucas SPs, ao contrário de projectos mais antigos que apanhei em outras empresas que tinha as centenas!

 

[hferreira.80]

Não há soluções perfeitas como tudo na vida.
Há escolhas.

SPs são muito práticas, correm ao nível do SQL, reduzindo a "resistência" ao mínimo no entanto o facto de correrem a esse nível, as torna na solução menos portável.

ExecuteSqlCommand com SQL direto permite uma performance incomparável com EF ou qualquer outro ORM por razões óbvias no entanto é mais portável do que SPs.
Eu tento fazer um SQL com a melhor performance possível e ao mesmo tempo algum cuidado para ser algo standard.

É por ter este cuidado é que foi possível migrar uma solução de 1 milhão e meio de linhas de código de .NET Framework para .NET Core.
Apesar do .NET Core à data de hoje falhar miserávelmente no suporte de algumas API's, já suporta muita coisa. Até o legacy DataSet o qual discordo porque vai transformar noutra mante de retalhos.

O .NET Core tal como o nome indica depois de ser algo muito light e standard e DataSet's deveriam de ser add-ons.
Eu como não uso DataSet's há mais de 5 anos, não tinha de carregar com esse cavalo morto.