Nous sommes sur le point de commencer le développement sur un site Web de taille moyenne ASP.NET MVC 2. Pour une page typique, nous saisissons des données et jetons-le sur la page Web, c'est-à-dire que vous n'avez pas beaucoup de prétraitement des données avant qu'elle ne soit envoyée à l'interface utilisateur.
Nous prenons maintenant la décision d'utiliser ou non une ormission et si oui, lequel. Nous avons examiné EF2 AKA EF4 (ASP.NET Entity Framework dans VS 2010) comme une possibilité.
Cependant, je pense qu'une solution simple dans ce cas peut être juste pour utiliser des datatables. La raison étant que nous ne prévoyons pas de déplacer les données autour ou de le traiter beaucoup une fois que nous l'extrairs, je ne suis donc pas sûr qu'il y ait beaucoup de valeur dans des objets fortement dactylographiés en tant que DTO. De plus, nous évitons de la cartographie de la cartographie, je pense que simplifier le code et permettre un développement plus rapide.
Je devrais mentionner le budget est un problème de ce projet, ainsi que la vitesse d'exécution. Nous nous efforçons de simplicité partout où nous pouvons, tous deux pour garder le budget plus petit, le calendrier plus court et la performance rapide.
Nous n'avons pas encore complètement décidé cela, mais nous vous appuyons actuellement vers aucun or. Allons-nous d'accord avec l'approche sans orme ou est une orme en vaut la peine?
6 Réponses :
Si vous n'allez pas pratiquer la programmation orientée objet complète (et que je veux dire que vous devez avoir une compréhension très profonde de OOP, pas seulement la possibilité de blinder les principes et les noms de modèle de conception) alors non, il est ne vaut pas la peine d'aller pour un orm.
Un orm n'est utile que si votre organisation est entièrement investie dans la conception d'applications orientée objet et que vous avez donc le problème d'avoir un objet à la cartographie du modèle relationnel. Si vous n'êtes pas entièrement dans OO, les ormes deviendront une sorte de barrage routier méchant que votre organisation aura alors besoin de ne pas avoir besoin.
Si le style de programmation de votre équipe / organisation s'est toujours penché pour maintenir la logique commerciale dans la DB (par exemple, les PROC stockés) ou s'accumuler à une approche plus ou moins fonctionnelle / procédurale / statique à la rédaction d'objets et de méthodes, éliminez les ormes et coller à ado.net.
Un outil orm n'est pas obligatoire!
Le conseil de Jon est sensible, mais je pense que l'utilisation de datables n'est pas idéale.
Si vous utilisez un outil ORM, le modèle d'objet est beaucoup plus simple qu'un modèle de domaine OO complet. De plus, LINQ2SQL et subsonique , par exemple, sont simples à utiliser. Permettant de changer de code très rapide lorsque la base de données change.
Vous dites que vous ne déplacez pas les données autour ou de le traiter beaucoup, mais une quantité de traitement sera beaucoup plus facile dans les objets ORM plutôt que dans les datables. Encore une fois, si l'application change et plus de traitement est nécessaire, la solution de données sera fragile.
Il semble que vous n'avez besoin que de montrer des données et ne faites pas de crud.
J'ai trouvé que ORM n'est pas le meilleur moyen d'y aller lors de l'affichage des listes qui consiste en des données de différentes tables. Vous finissez par charger de grands scargraphs pour obtenir celui-ci nécessaire.
Une déclaration SQL est tellement meilleure à cela. Je retournerais toujours des listes d'objets fortement typés du DAL. De plus, vous avez de meilleures chances d'obtenir une erreur de compilation lorsqu'un changement de DAL n'est pas reflété dans d'autres couches.
Si vous avez déjà stocké des procédures stockées, vous n'avez probablement pas autant de choses à gagner d'un orj. Sinon, bien que mon expérience ait été que travailler avec Linq pour participer a été beaucoup plus rapide que la procédure stockée traditionnelle / une approche de jeu de données fortement tapé en supposant que vous êtes à l'aise avec les requêtes LINQ.
Si vous n'êtes pas inquiet de la mappage à un modèle d'objet, Linq à SQL est encore plus simple à utiliser. Vous n'avez certainement pas besoin d'utiliser un modèle OO complet pour récolter les avantages de la productivité.
Il serait désaccord avec le point de Malcolm sur le point de devoir ramener des graphiques, si l'OrM prend en charge LINQ, vous pouvez utiliser une projection pour renvoyer un résultat plat avec uniquement les données souhaitées avec l'avantage supplémentaire que la requête est généralement plus simple que la SQL correspondante. Puisque vous pouvez utiliser des relations plutôt que de rejoindre.
Après avoir fait le commutateur et devenez à l'aise avec la technologie que je peux penser à ce point de ne pas utiliser la seule raison de ne pas l'utiliser, ils soutiennent tous les procédures stockées SQL si vous avez vraiment besoin. Il y aura une courbe d'apprentissage cependant et dans ce cas peut ne pas valoir votre peine.
Je suis d'accord avec les conseils de Joe R - pour la rapidité des changements et la rapidité du développement initial, Linq-to-SQL ou SUBSTONIOM vous permettront de ne pas faire de temps.
Si votre application est vraiment aussi simple et que ce n'est que des données droites ou des données dans la cartographie directe sur les tables, avez-vous considéré comme regarder Données dynamiques ASP.NET ?
Je voudrais également indiquer un bon article à ce sujet par Scott Guthrie.
Cela dépend en grande partie de la familière avec les ormes.
Je pense personnellement que NHibernate, qui est le roi des ormes du monde .net, permet un développement beaucoup plus rapide qu'après la mise en place, vous pouvez à peu près oublier comment vous obtenez des données de la base de données.
Cependant, il y a une courbe d'apprentissage escarpée, surtout si vous essayez de faire des choses de manière non hacable (que vous devriez), donc si votre équipe n'a pas d'expérience ici et que le temps appuie probablement que c'est probablement ne le coupera pas.
LINQ2SQL est trop simple. Je ne sais pas de subsons, mais si vous allez utiliser un orj, il peut s'agir d'un bon équilibre entre avoir un développement rapide et de devenir quelque chose de trop puissant et complexe.
En fin de compte, en tant qu'équipe, je pense que vous voulez apprendre NHibernate, ce qui ne prend pas de temps à mettre en place sur un projet petit à moyen une fois que vous savez ce que vous faites, mais est très puissant.
Peut-être d'intérêt: Stackoverflow.com/questions / 18655 / why-do-we-we-we-webje cts ayant personnellement des objets fortement dactylographiés, dans vos pages, qui peuvent simplement être moqués, c'est beaucoup plus facile pour les tests que de se moquer de choses comme des jeux de données tels que en avant.