Quelle est la meilleure architecture pour un site Web de taille moyenne à fort trafic?
architecture asp.net-mvc dapper entity-framework performance
Question
Je commence un nouveau projet (non-corporatif) et je veux savoir comment serait une grande architecture de nos jours.
Ce que je prévois pour le moment est d'utiliser:
- ASP.NET MVC 4.0
- SQL Server 2008 ou 2012
- EF 5.0 sous .NET 4.5, avec Dapper
- Implémentation du modèle de référentiel (celui-ci http://code.google.com/p/ef4prs/ )
- DI avec Autofac
- Automapper
- Couche de service WCF (pour la future implémentation mobile)
Vérification du flux (corrigez-moi si quelque chose ne va pas): Le contrôleur appelle ApplicationService , qui appelle un BusinessLayer , qui appelle DAL avec UnitWork / Repository, qui exécute des requêtes sur EF ou Dapper (est-il correct d'interroger Dapper à partir d'une méthode spécifique dans Repository? ), le résultat est automatiquement mappé sur un DTO et renvoyé à Controller , qui copie ce qui est nécessaire dans un ViewModel et renvoie une vue.
Le problème ici est la performance, comme je le disais, le site devrait avoir un trafic élevé. Dans ce cas, l'un des éléments énumérés ci-dessus pourrait réduire les performances? Ou cette combinaison fuit-elle quelque chose de plus? Dois-je supprimer l'EF et utiliser uniquement Dapper? Je crains que la couche de service ne réduise les performances en raison du trafic.
Et enfin, je ne sais pas si cette architecture est inutile ou simplement médiocre.
C'est beaucoup de questions, mais l'accent est mis sur la connaissance d'une solution géniale et non "sur-architecturée" pour un site Web de taille moyenne.
Désolé pour l'anglais
Réponse acceptée
Votre question est assez subjective car il existe de nombreuses configurations possibles qui peuvent toutes fonctionner correctement. Je peux cependant vous donner quelques recommandations.
Mélanger et assortir EF avec Dapper peut être un peu un champ de mines. En théorie, vous devriez être en mesure d'aller chercher des objets avec Dapper puis Attach - les à la DbContext et les mettre à jour. Cependant, dans mon expérience, cela ne fonctionne pas souvent. Nous avons commencé avec EF, puis nous sommes lentement passés à Dapper pour une interrogation rapide et je pensais que nous pourrions continuer à utiliser EF pour les mises à jour / insertions, mais j'ai fini par lancer mon propre suivi d'insertion / mise à jour. utilisation de EF.
Avec le recul, je suggérerais d'en choisir un et de le suivre. EF devrait être assez rapide sous .NET 4.5. Pas aussi rapide que Dapper, donc la route Dapper n'est pas une mauvaise idée à prendre.
Autres technologies que vous pourriez envisager:
- ServiceStack (webservice) http://www.servicestack.net/ . Fortement recommandé, faible configuration, rapide et facile à utiliser.
- ASP.NET MVC Web-API (webservice) http://www.asp.net/web-api . Je n'ai aucune expérience avec ça.
- ThisMember (mapper, disclaimer: ma propre bibliothèque ) https://github.com/JulianR/ThisMember/wiki . Beaucoup plus rapide (10-100x) que AutoMapper et plus facile à utiliser à mon avis.