Subsonic Vs NHibernate

Quel est le consensus sur le moment d'utiliser un de ces outils adverses à l'autre? Je trouve Subsonic très utile pour faire avancer les choses rapidement, mais sur les grands projets, il a tendance à ne pas évoluer, et il relie votre modèle de domaine à votre modèle de base de données. C'est là que Nhibernate intervient car il vous donne des POCO légers qui ne sont pas liés à votre modèle de base de données, mais le temps d'installation est beaucoup plus long.

0

13 Réponses

Nous avons amorcé avec subsonic et essayons maintenant d'évaluer si nous allons passer à nhibernate maintenant que nous sommes aux points de douleur de subsonic.

Notre autre option est de créer un terrain d'entente où nous utilisons subsonic pour interroger et charger des objets arbitraires avec leur fonctionnalité "execute as typed list" qui fait un mapping basé sur le nom d'une instruction sql style linq arbitraire. Ou essayer d'en recréer une partie dans nhibernate et refactoriser le reste.

Donc, je dis que subsonic est logique dans les petites applications, mais la maintenance sur les applications subsoniques devient assez poilue, nous avons des moments particulièrement difficiles avec le chevauchement du code de validation, et pré / post dans les événements déclenchés par le code. Pour un pattern d'enregistrement actif, subsonic est définitivement à 80%, mais fait quelque chose de manière flou, et vous empêche d'avoir un réel contrôle sur votre hiérarchie d'héritage, puisque chaque classe doit hériter d'une table pour revenir à cette table.

0
ajouté

Je pense que vous l'avez presque réussi. Subsonic génère du code, de sorte que vos objets métier reflètent la structure de votre base de données. nHibernate utilise des fichiers de mappage qui mappent vos objets métier à la base de données afin que vos objets puissent être structurés comme vous le souhaitez.

Quelle est la taille d'un projet? Y aura-t-il un soutien à long terme nécessaire? La rentabilité de Subsonic va-t-elle compenser d'éventuels problèmes d'échelle?

0
ajouté

Un peu hors sujet, mais dans la même veine. Avez-vous regardé Castle ActiveRecord il est écrit au-dessus de NHibernate et supprime le besoin de passer du temps à créer des mappages xml à partir du code dans la base de données. Comme NHibernate vous pouvez structurer vos objets de domaine comme vous voulez et ensuite générer un schéma de base de données à partir de cette structure.

En utilisant ActiveWriter , un outil contribuant, vous pouvez facilement mapper de votre base de données aux objets de domaine.

0
ajouté
Je joue avec CAR sur un projet pilote maintenant. Je l'ai choisi parce que j'aime l'idée d'ActiveRecord en plus de quelque chose d'aussi bien testé que NHibernate. Si je finis par ne pas aimer la voiture, je peux revenir à la pure NHibernate. Cela me donne une sortie en toute sécurité - j'aime ça. Je vais essayer Subsonic dans quelques mois pour la comparaison.
ajouté l'auteur BuddyJoe, source

Pour ce que ça vaut ... J'ai eu l'occasion d'utiliser les deux technologies assez abit plus depuis que j'ai posé cette question. Et je dois rester que si ces technologies vous choisissez très peu. Bien sûr, NHibernate permet à vos entités commerciales d'être légèrement moins couplées à la structure de votre base de données, mais je trouve toujours qu'il y a de nombreuses occasions où vous devez encore vous plier à la volonté de la base de données.

À mon avis, la seule façon de séparer complètement votre modèle de domaine de votre modèle de base de données est d'écrire votre propre DTOS (essentiellement des POCO pour transmettre des données), puis les mapper vers votre ORM de votre choix dans votre couche de données. Mais dans la plupart des cas, cette approche me causera plus de tracas que de sa valeur.

0
ajouté

Je recommande SubSonic si votre projet fonctionne avec la vue ActiveRecord que la base de données est votre modèle. Vous obtiendrez une classe par table et tout fonctionne comme par magie. Vous pouvez bien sûr modifier et ignorer les choses, mais si vous (ou votre projet) êtes fondamentalement en désaccord avec l'approche de classe par table, je regarderai NHibernate car cela commence par l'approche plus complexe (mais plus flexible) de cartographier votre modèle de domaine à votre base de données.

Si vous utilisez une base de données relativement simple (comme dans, vous pouvez changer de colonne sans envoyer huit formulaires à un comité de révision de supervision de la base de données), je recommande de commencer par SubSonic et de passer à NHibernate si SubSonic ne le fait pas. répondre à vos besoins.

0
ajouté

I a écrit un article de blog sur les ORM .NET qui contient Subsonic et ActiveRecord. D'après mon expérience, cela dépend de ce que fait le projet, Subsonic fonctionne beaucoup mieux si vous venez d'un arrière-plan SQL mais NHibernate en a plus. ActiveRecord est bon pour les projets plus petits, je ne suis pas convaincu que c'est plus rapide pour les projets plus importants que coller à NHibernate.

0
ajouté
Le lien que vous avez fourni ne fonctionne pas. Est-ce que tu veut dire ça? shrinkrays.net/articles/a-look-at-dotnet- orms.aspx
ajouté l'auteur kimsk, source

Je crois que vous devriez vous en tenir à celui que vous pouvez utiliser le meilleur. Le but ultime est la productivité et le bon code de qualité. Si vous connaissez SubSonic in and out, respectez-le et si vous savez que NHibernate en profondeur s'en tient à NHibernate. C'est une question très subjective. Vous devriez également tenir compte du fait que votre équipe possède une expertise. Si vous êtes bon, vous pourrez facilement le maintenir.

J'ai vu de grands projets utilisant SubSonic alors que NHibernate est déjà célèbre et largement utilisé.

La décision de choisir ORM n'est pas    dépend uniquement de l'ORM lui-même.

0
ajouté

J'ai évalué les deux et je crois qu'il ne serait pas juste de recommander l'un par rapport à l'autre sans comprendre quels sont vos objectifs. Dans votre question, vous avez bien exprimé les différences et je crois que cela doit être votre facteur décisif. Personnellement, j'ai utilisé les deux et continuerai à utiliser les deux selon le projet.

  • NHibernate est mon choix pour les projets à plus grande échelle car ses utilisations de POCO légers. Si je devais changer mon ORM "je crois", ce serait beaucoup plus facile à refactoriser.
  • SubSonic est mon choix quand j'ai un projet à plus petite échelle. Je crois que les performances de SubSonic évoluent bien. Cependant, je me sens étroitement lié à cela parce qu'il est tellement gravé dans mon projet. Dans un petit projet, je peux encore le changer parce que la base de code est si petite et cela m'aide vraiment à déchirer le code comme annoncé.
0
ajouté

Je ne peux pas faire une bonne comparaison car je n'ai pas encore utilisé NHibernate sur un projet, mais j'ai utilisé SubSonic et j'en suis très content. Jusqu'à présent, je n'ai pas rencontré d'obstacles majeurs lors de l'utilisation.

Découvrez cet article de Rob Conery, l'un des créateurs de SubSonic. Il parle de la façon de découpler votre code SubSonic du reste de l'application. Il mentionne même le fait que cette architecture vous permettrait d'échanger ultérieurement SubSonic pour d'autres couches d'accès aux données telles que NHibernate ou LINQ to SQL.

Je sais que je n'ai pas vraiment répondu à votre question, mais j'espère que cela aidera encore.

0
ajouté

Encore un peu hors-sujet, mais je vais seconder Castle ActiveRecord - plutôt que d'utiliser le base de données en tant que votre modèle (approche subsonique) ou passer des heures dans des spaghettis xml (approche NHibernate) vous placez simplement des attributs sur vos classes de modèles.

Vous pouvez même obtenir ActiveRecord pour générer le schéma de base de données pour toi.

Nous avons utilisé cette approche sur un certain nombre de projets maintenant et les avantages sont les suivants:

  • Easy upgrade path to NHibernate if required in the future
  • Support for simple inheritance models - eg. Car -> Vehicle
  • The schema it generates is most likely how you would have created it anyway, so you can spend more time building the app rather than worrying about keeping your model/db in sync.
0
ajouté

Tenez compte de la taille de votre équipe et de votre projet lorsque vous envisagez d'utiliser ActiveRecord.

Dans mon expérience, ActiveRecord est une abstraction au-dessus de NHibernate qui commence à fuir comme un tamis en essayant des scénarios plus compliqués.

Si vous avez un schéma modérément à compliqué ou non simple, respectez NHibernate. Vous pouvez couper et couper en dés à la perfection près.

L'autre endroit où vous pourriez avoir des ennuis est quand vous avez besoin d'une requête modérément compliquée. ActiveRecord cache une grande partie de l'implémentation de NHibernate ... mais vous en aurez besoin pour une requête compliquée, ce qui deviendra très difficile si vous n'êtes pas familier avec HQL. Attention, les membres de l'équipe ne se contentent pas d'attaquer les bords au lieu d'apprendre NHibernate et HQL.

0
ajouté

Le conseil que j'ai reçu sur le sujet est que Subsonic ne s'adapte pas à des scénarios plus complexes et que si vous continuez sur cette voie, vous finirez avec un travail qui tente de passer à un ORM plus avancé.

Je suis donc plus intéressé par l'utilisation de NHibernate pour les cas complexes, Castle Active Record pour les cas plus simples et je garde un œil sur Fluent NHibernate ce qui devrait faciliter le mappage de NHibernate (surtout une fois le support de mappage basé sur les conventions amélioré).

0
ajouté
Si vous avez des preuves de problèmes de mise à l'échelle subsonique, veuillez fournir. Je n'ai personnellement rencontré aucun problème avec l'évolutivité de SubSonic.
ajouté l'auteur Jim Geurts, source
"que Subsonic ne s'adapte pas pour gérer des scénarios plus complexes" Le problème avec ceci est que juste dire cela ne veut rien dire. Il y a toujours un manque total de preuves crédibles que SS ne fait pas évoluer. Je suppose que c'est la preuve qu'il suffit parfois de dire quelque chose sur Internet.
ajouté l'auteur CarmineSantini, source

Embrassez la discordance d'impédance!

vérifier cela

:)

Ou ne le fais pas. Si vous voulez de la performance, faites-le vous-même. Si vous le voulez rapide et facile, allez avec NHibernate et ActiveRecord. Si vous voulez prétendre savoir réellement ce qui se passe au niveau de l'accès aux données, utilisez NHibernate et asseyez-vous avec xml tout au long de la journée pour en avoir beaucoup à faire ... Ou juste ... faites-le vous-même - ADO.Net FTW!

0
ajouté
Le même Stephen Forte, maintenant (en décembre 2010) affirmant que «la nouvelle génération d'outils ORM continue d'évoluer, ils deviennent plus agiles et plus faciles à utiliser, ce qui incite davantage de développeurs à intégrer l'ORM dans leurs architectures applicatives. ". Il n'y a rien comme le temps de ramener un homme à ses sens! :-) devproconnections.com/article/tools-and-products/…
ajouté l'auteur rsenna, source