Ecrire des requêtes dans le code vs. SqlDataSource

Question

J'ai toujours eu cette idée que l'écriture de requêtes SQL dans le code n'est pas bonne comparée à l'écriture de requêtes à l'aide d'une source de données SQL.

SqlDataAdapter ad = new SqlDataAdapter("SELECT * FROM Categories", myConnection);

DataSet ds = new DataSet();

ad.Fill(ds, "Categories");

myGridView.DataSource = ds;

myGridView.DataBind();

vs.

<asp:SqlDataSource ID="SqlDataSource1" runat="server"
  ConnectionString="<%$ ConnectionStrings:myConnection %>"
  SelectCommand="SELECT * FROM Categories" />

Je pense que l'utilisation de SqlDataSource est sûre et facile à maintenir. Mon inquiétude est-elle fondée ? Veuillez justifier.

Answer 1

Je n'écrirais pas de requêtes SQL en code derrière un point final. Pourquoi pas une couche d'accès aux données ?

Que se passe-t-il si vous souhaitez changer de magasin d'adossement ? Vous allez devoir réécrire tout votre code-behind.

Que se passe-t-il lorsque vous devez utiliser les données à plusieurs endroits ? Vous dupliquez le code.

Vous devez réfléchir sérieusement à l'architecture de votre solution avant d'écrire des requêtes SQL dans votre code. Pensez à la séparation et à la maintenabilité bien avant de remettre en question la "sécurité" des objets SqlDataSource. Sérieusement.

Answer 2

Les requêtes SQL dans le code-behind et les requêtes SQL dans une SqlDataSource sont pratiquement équivalentes.

Les deux sont à peu près au même niveau de sécurité ; en ce qui concerne la facilité de maintenance, SqlDataSource peut être un peu plus facile dans la plupart des cas.

Une couche d'accès aux données est préférable, mais SqlDataSource est parfois un bon expédient. Je ne vous infligerais pas un journal roulé pour l'avoir utilisé si vous n'aviez pas déjà une couche d'accès aux données et s'il s'agissait de quelque chose de simple ou d'unique.

Answer 3

Aucune de vos méthodes n'est plus ou moins sûre que l'autre. Étant donné que vos pages aspx sont compilées tout comme votre code derrière les pages, vous ne courez pas le risque d'exposer accidentellement vos instructions SQL ou la structure de votre base de données en utilisant simplement SqlDataSources. Cependant, la sécurité n'est pas votre principal problème ici - c'est la maintenabilité.

De nombreuses personnes se sont plaintes lorsque Microsoft a publié SqlDataSources dans le cadre de .NET 2.0 : nous pensons que cela encourage et renforce les mauvaises habitudes.

Pour tout type de projet plus important qu'une simple page intranet, vous devriez vous tourner vers son grand frère bien élevé, l'application ObjectDataSource . En utilisant un ODS, vous êtes presque contraint de développer un modèle séparé pour vos données, loin de votre vue.

Answer 4

D'après mon expérience, SQLDataSource est une bonne solution pour une page unique et rapide permettant d'afficher des données et éventuellement de les modifier. Mais dès que l'on entre dans un scénario compliqué (et c'est ce que j'ai toujours fait), il s'effondre assez rapidement. La maintenabilité est un cauchemar en utilisant à la fois SQLDataSource et SQL dans le code. SQLDataSource m'a fait du tort à de nombreuses reprises.

J'écrirais au moins une couche d'accès aux données sous la forme d'un assemblage séparé auquel vous pourriez faire appel. Vous disposerez ainsi d'un moyen enfichable de la modifier si nécessaire. Mieux encore, une solution d'accès aux données telle que NHibernate ou LinqToSql, qui gère la plomberie pour vous et vous évite d'avoir à tout écrire vous-même.

Answer 5

SQL in aspx ou aspx.cs sont deux approches vraiment novatrices et mauvaises. Consultez les ouvrages sur la conception n-tier / n-couche, la séparation des préoccupations et n'importe quel livre sur la conception de logiciels.