SqlDataSource vs ObjectDataSource

Question

Si une page Web a besoin de données, pourquoi ne pas demander à un SQLDataSource d’appeler une procédure stockée? Pourquoi utiliser un ObjectDataSource pour appeler un objet métier qui appelle ensuite la procédure stockée? Je comprends que d’autres applications (comme les applications de bureau) créées sur le framework .net peuvent accéder aux objets métier, mais qu’en est-il si l’application sera toujours une application Web?

Pour être plus clair:

Quand faut-il utiliser un SqlDataSource ou un ObjectDataSource ?

Comment motiver le choix?

Answer 1

Avoir juste un SQLDataSource est parfaitement valide, si c'est juste une démo, un prototype ou un piratage rapide. C'est rapide, facile, ça marche et vous donne les résultats dont vous avez besoin.

Cependant, quand une application est conçue et construite pour le long terme et prévoit que les choses (exigences, souhaits du client, éventuellement le schéma de la base de données) peuvent changer, il pourrait alors être beaucoup plus logique d'introduire un " entreprise " layer - modélisez vos objets métier sous forme d'objets, puis fournissez un mappage de la base de données sous-jacente à ces objets métier.

Comme le dit le dicton - vous pouvez résoudre à peu près n'importe quoi en informatique par une couche supplémentaire d'indirection (ou d'abstraction) - la même chose est valable ici.

SURE: vous pouvez accéder directement à la base de données et, bien sûr, au début et à la première itération, c’est peut-être (ou probablement) le moyen le plus rapide. Mais à long terme, lorsqu'une application est conçue pour durer, c'est généralement un moyen rapide - et sale : le coût de maintenance, le coût de la maintenance, le coût et les efforts nécessaires pour changer vos besoins et ceux de vos clients vont croître et assez rapidement, cette solution quick'n'dirty n’a plus l’air aussi fantastique, en termes d’effort.

Donc, pour résumer mon point: oui, au départ, utiliser une source de données SQL directe peut être plus rapide et plus facile - utilisez-le quand c'est le point important: faire avancer les choses pour une démonstration rapide, une preuve de concept application de style. Mais à long terme, lorsque vous examinez la durée de vie d'une application, il est généralement intéressant d'investir un peu plus (conception et codage) pour ajouter cette couche d'abstraction afin que vos pages Web ne dépendent pas directement des détails de la base de données ci-dessous.

Marc

Answer 2

Si vous utilisez une couche de gestion dans vos projets, ObjectDataSource est le choix naturel. Cela convient bien à de nombreux ORM, et beaucoup d’entre eux offrent des avantages supplémentaires (validation, annulation, etc.). Il vous permet également d’accéder aux autres propriétés & amp; méthodes que vous avez sur vos objets métier - pas seulement les champs SQL directs. Cela peut s'avérer très utile lors de la liaison - car cela vous permet de simplement lier des propriétés dans le balisage au lieu d'avoir à écrire beaucoup de code derrière.

Si vous choisissez cette voie, le mélange de SQLDataSource et ObjectDataSource peut être source de confusion pour le développeur suivant qui prendra votre projet. Dans ce cas, je reste avec ObjectDataSource pour la cohérence du code.

Si vous ne possédez pas de couche de gestion et utilisez uniquement SQL directement, utilisez SQLDataSource. Ma préférence personnelle est que tout votre code SQL soit dans une couche métier ou une couche de données et que je n’utilise presque jamais SQLDataSource.

Answer 3

si vous pouvez appliquer votre code de couche de gestion dans la procédure stockée il vaut mieux utiliser SQLDataSource

Answer 4

En théorie, objectdatasource est préférable. Mais tout dépend de la qualité de l'écriture et de la documentation du modèle d'objet. Nous avons sous-traité une entreprise qui utilisait un générateur de code personnalisé (qu'elle ne nous fournirait pas) pour produire toutes les couches. Il s'est avéré être cauchemardesque d'apporter de petites modifications, telles que l'ajout d'une propriété ou la modification d'un type de champ. Je suis en train de supprimer pratiquement tout ce qu'ils ont fait et d'utiliser simplement les procédures stockées qu'ils ont écrites.

Mon objectif à long terme est de réécrire l'application à partir de la base à l'aide d'un outil de modélisation commercial & amp; générateur de code. Si vous allez utiliser objectdatasource, je vous recommande vivement de trouver un bon outil de modélisation incluant un générateur de code flexible.