Discussion :

[trihanhcie]

Hello a tous,

J aimerais avoir un avis sur l'etat actuel de Asp.net MVC (et asp.net egalement) sur le marche du travail.
Je m'explique... On va dire que, a l'heure actuelle, les nouveaux projets "Web" n utilisent plus les Webforms. Depuis quelques annees, il me semble que la tendance est plutot vers l'utilisation d'Asp.net MVC...Cela n'est que mon avis, mais c'est comme ca que je vois l etat du marche du travail en .Net. Cela ne me gene pas car je trouve Asp.Net MVC plutot simple a mettre en place et avoir le control total de l HTML est en soit un gros avantage.
Bref tout cela pour dire que le transition vers Asp.Net MVC ne me gene pas et j'y suis plutot favorable.
Seulement voila ... Depuis maintenant 1 an (peut etre un peu moins), je constate que Asp.net MVC est moins a la mode... au profit de framework JS comme angularJS ou EmbedJS ou autre... L'utilisation de "asp.net MVC" revient l'utilisation de WebApi avec l'utilisation ou autre...

Du coup... Je trouve qu'il y a un dilemne si je puis dire... Quel etait un des gros avantages de Asp.Net ou Asp.Net MVC dans une certaine mesure pour moi?
Tout simplement que, dans une certaine mesure, le developpeur pouvait realiser 80% d'un site avec du pur javascript / jquery et du .Net. On va dire que les 20% sont pour ceux qui, comme moi, n'ont absolument pas le sens du design et a du mal avec le css . Les controles .Net sont "standard" et l'html etait "standard"

Qu'en est-il aujourd'hui... on se retrouve avec un backend en .net ce qui, en soit, est tres bien... qu'en est-il du front end... Je ne me suis pas encore mis vraiment a angularJS mais, de ce que je comprends, c est rajoute des attributs dans les differents elements HTML...A part que ces attributs qui sont
rajoutes pour un framework JS ne sont pas les memes que pour un autre ...
Resultat, tant qu il n'y a pas un frameworkJS qui s'impose, que choisir???

Ma question est la suivante. Si on devait suivre la tendance du marche, est-ce que vous choisiriez de :
- d'apprendre Asp.net
- d'apprendre Asp.net MVC 'a l ancienne' (sans frameworkjs)
- d'apprendre Asp.net MVC avec un framworkJS specifique (que ce soit angularJS ou autre)

Je trouve qu'on est dans une periode a la fois frustrante et interessante si on est plutot interesse par le developpement Web. Interessante car tout bouge tres vite (dev pour mobile, html 5 etc etc) et frustrante car il est difficile de predire l avenir du marche et si un framework JS s'imposera vraiment par rapport aux autres...

Desole pour les accents manquant je suis sur un clavier anglais

[GuruuMeditation]

Je suis orienté client Windows, et, d'après ce que je vois passer en ASP, c'est toujours du MVC. Des projets Webforms, je n'en ai plus vu depuis des années.
Du MVC 100%pur, c'est assez rare. Souvent, il y a au moins JQuery.

Donc je dirais d'apprendre MVC avec des frameworks, je pense que ça arrivera plus souvent que sans Framework.

Tout ça d'après mon expérience limitée

[trihanhcie]

Oui quand je vais préciser dans ce cas.
Lorsque je parle de MVC sans framework, je veux parler d'un framework MVC type angularJS plutot que d'utiliser uniquement du "simple" Javascript / Jquery (ou les libraries type jquery UI ou autre)

[dkmix]

Bonjour,
La réponse est dans la question je pense

avoir le control total de l HTML est en soit un gros avantage.

ASP MVC gère le côté serveur
Pour le côté client tout est possible, selon le besoin, les qualifications, l'envie, un framework style jquery, un framework MVC/MVVM JS (pour faire son choix : TodoMVC)

Personnellement j'utilise généralement un framework CSS (j'aime pas le CSS ) Twitter Bootstrap avec du JQuery

[trihanhcie]

Ce qui me gêne, si on peut dire, c'est que de Asp.NET MVC, avec les nouveaux framework JS MVC ou autre, il ne reste finalement plus que ".Net MVC". En gros, il ne reste plus que le cote WebService...
Je ne connais pas la complexité des framework JS MVVM / MVC mais...
Il y a ... mmm on va dire un peu moins de 10 ans, si on voyait "Dev confirmé en Asp.Net" on peut imaginer que cette personne saura réaliser un site Web de A à Z en utilisant du jquery ou javascript cote Front End. Même chose si on voyait une offre telle que "Dev Asp.Net MVC".
Par contre... qu'en est-il aujourd'hui? Une personne spécialisée dans Asp.Net MVC + AngularJS sera-t-elle capable "facilement" d'apprendre Ember?

L'abondance de framework JS est peut-être une bonne chose mais, d'un autre coté, cela ne nous oblige-t-il pas de nous spécialiser sur un framework JS donné?

[dkmix]

Je pense qu'il faut différencier deux type de controleur :
System.Web.Http.ApiController (WebApi, REST ) VS System.Web.MVC.Controller
(MVC "Classique")
Je ne connais pas angularjs mais si je comprends bien il se branche sur un web-service REST.
Les deux approches sont légèrement différentes et ne devraient pas (à mon avis) se retrouver sous la même appellation "ASP MVC"
Avec WebAPI / REST on privilégie fortement le côté client, en contre partie on obtient plus de modularité (on peut changer de framework client sans toucher une ligne de code côté serveur et inversement). Par contre on peut facilement complexifier l'appli et dupliquer de la logique métier. En plus çà implique de bien connaitre deux chose complètements différentes : le JS et le DotNet.
Je préfère l'approche ASP MVC "classique" / jquery / framework CSS qui permet de faire du Html5 "standard" sans trop s'arracher les cheveux.

[trihanhcie]

dkmix,
Je suis d'accord avec toi pour la différentiation.

Pensez-vous que les 2 approches vont continuer à coexister?

[chrisdot]

Intéressant ! On a eu le même genre de réflexion il y a quelques mois.

Je ne vois pas la situation de la même manière: ayant des compétences majoritairement orientées client lourd (winforms, puis SL/WPF), je vois la nouvelle manière de faire plus proche de ce que je connais: les "sites webs" se sont mués en "applications web", les fameuses RIA / SPA (single page application). On ne ballade plus des états de page entre client et serveur, puisque le client est devenu plus intelligent. Maintenant il demande les données dont il a besoin, il ne se satisfait plus simplement de l'affichage brute d'une page HTML.
Javascript ne sert plus uniquement à valider quelques données ou à animer/rendre plus sexy, mais devient la colonne vertébrale de l'application web. Cela modifie profondément la façon de voir les choses. Ca simplifie certaines choses (le contexte est local au client de la même façon qu'un client lourd), mais ça entraîne des complications côté client: choisir des outils, maîtriser réellement javascript, etc... Mais aussi du côté serveur: nécessité de gérer des services RESTFull, sécurisation etc...
Du coup ça nécessite de choisir des outils adaptés: le Framework côté client entre autres est un des points clés à mon sens. Nous avons choisi notre Framework client par rapport à notre expérience (il y en a plein en liberté !!)

Je ne connais pas angularJs, mais ce que j'ai pas compris dans ton cas c'est que le html serait "tiré par les cheveux".?.. Ce n'est pas le cas avec notre framework.