MVC, WCF, EF, LINQ - Sou apenas eu? [fechadas]

... ou as coisas estão ficando mais complicadas?

Parece-me que você precisa saber muitas coisas para desenvolver 'adequadamente' um aplicativo da Web da Microsoft hoje em dia. Nos velhos tempos em que não sabíamos melhor, tínhamos tabelas de banco de dados, ASP.NET, ADO.NET e você construiu um aplicativo da Web usando conceitos relativamente simples.

Hoje em dia, parece haver muita estrutura para 'ajudar' você a fazer o 'certo', mas não estou convencido de que isso torne tudo mais fácil e melhor. Tenho a sensação de que estarei em uma minoria bem pequena com esse sentimento, mas há alguém por aí que acha que as coisas ficaram um pouco loucas?

Todas essas coisas são opcionais, use-as se forem úteis, não se não forem. É simples assim. Certamente, você pode escrever aplicativos da Web bons / adequados sem nenhum desses acrônimos em sua solução.

Pessoalmente, tenho a tendência de achar o MVC uma estrutura bastante leve e fácil de usar (muito mais fácil de começar do que formulários da web, em particular). Da mesma forma, o LINQ fornece uma maneira comum de consultar qualquer coisa; também é bom. EF e WCF e eu tivemos nossas divergências, mas quando é esse o caso, eu não as uso.

Não, na verdade não. O LINQ é a melhor coisa desde o pão fatiado ao interagir com um banco de dados.

O que você deve se lembrar é que essas coisas são construídas sobre outras coisas. O LINQ não está aumentando o número de coisas que você precisa saber para desenvolver um site ASP.NET, porque agora você não precisa conhecer o SQL. E o LINQ é OO, que está muito mais alinhado com o desenvolvimento regular de aplicativos, o que torna um shitton completo mais fácil de fazer do que o SQL e muito mais fácil de integrar ao C #.

Se você não acha que o LINQ é mais fácil que o SQL, talvez você deva postar alguns exemplos de algo mais difícil nos novos paradigmas.

Mais importante, os sites anteriores tinham muito menos funcionalidade. Como você criará novos sites com melhor desempenho, escalabilidade e oferta de novas funções no mesmo código?

Se os conceitos antigos que você mencionou não funcionassem mais, eu concordaria que seria uma loucura, mas as novas estruturas são alternativas. A aceitação cega seria louca. Você precisa justificar. Pessoalmente, o SQL em si não é um problema para mim. Tentando adicionar algumas das funcionalidades dos sites modernos, os webforms não estão mais diminuindo.

Tenho certeza de que algumas pessoas clássicas do ASP sentiram o mesmo sobre o .NET, mas poucas podem continuar a argumentar. Eu construo alguns sites no ASP clássico e não voltaria atrás.

"Ficou um pouco louco". É exatamente assim que eu descreveria uma DataSetsolução ADO.NET, ASP.NET. :)

Concordo que há muito mais a aprender, mas cada uma das estruturas mencionadas melhorou o desenvolvimento do .NET.

Eu diria que esse é um problema global que pode afetar praticamente todas as estruturas ou plataformas (de desenvolvedor). Quando uma nova estrutura é lançada, ela geralmente parece pequena e compacta, mas com o passar do tempo e novos recursos / funcionalidades / APIs são incluídos (por roteiro / solicitação, novos conceitos / tendências / tecnologias ou simplesmente pela evolução), ela fica "inchada". Você começou com "uma maneira de fazer as coisas" e agora há mais possibilidades de escolha (e - você não sabe / não tem certeza - qual escolher). Pode ser demorado aprender coisas novas, mas elas podem oferecer soluções muito mais flexíveis / rápidas / melhores para os mesmos problemas que foram resolvidos anteriormente por um conjunto limitado de opções.

Certa vez, me deparei com uma citação engraçada - "todo código se transforma em um tempo e mãos suficientes" - que IMHO resumem por que novas coisas dentro das estruturas existentes devem surgir para trazer novas idéias para a ação e fazer a evolução.