La création d'Une Instruction Insert — application Windows Vb.Net
Je suis en train de faire de windows appliction dans vb.net. j'ai client de l'objet contient la méthode save. comment puis-je générer de la requête d'insertion?
J'ai besoin d'enregistrer l'objet dans la base de données relationnelle (SQL server). J'ai besoin de savoir qui est la bonne façon de faire de l'insertion, c'est à dire,. À l'intérieur de la méthode d'enregistrement que j'ai écrit l'instruction SQL pour enregistrer l'objet. Est-ce la bonne manière?
Grâce
- Êtes-vous demander à propos de comment créer une instruction insert dans la base de données? Si oui, lequel?
- Demandez-vous comment (la syntaxe) pour écrire une instruction SQL insert ou de la procédure de programmation pour exécuter une instruction SQL?
Vous devez vous connecter pour publier un commentaire.
D'une simple instruction INSERT pour SQL prend cette forme de base:
Donc, nous avons évidemment besoin de savoir à propos de la table de base de données que vous utilisez: ce que les colonnes dont il dispose. Nous avons aussi besoin de savoir à propos de la classe: quelles sont les propriétés qu'il possède. Enfin, nous avons besoin de connaître les types de données pour les colonnes de la table et des propriétés de la classe, et comment les propriétés de la carte pour les colonnes. Pour des objets très simples, les noms et les types de juste ligne. Mais dans d'autres cas, votre classe peut lui-même contenir une collection (ou plusieurs) qui signifierait l'insertion de données dans plus d'une table.
Après tout cela est déterminé, nous avons encore besoin de deux choses: les informations de connexion pour la base de données (généralement distillé en une seule chaîne de connexion) et si vous craignez que votre instance de classe peut avoir été préalablement enregistrée, dans le cas où vous voulez construire une instruction de mise à JOUR plutôt que d'INSÉRER.
En supposant que vous pouvez répondre à tous que, dans une manière satisfaisante, votre VB.Net le code devrait ressembler à quelque chose comme ceci (bien sûr en remplaçant votre colonne spécifique, la propriété, le type et les informations de connexion, le cas échéant):
.
Je sais que vous avez déjà entendu dire que le fait de séparer votre code de base de données est "la bonne chose à faire"tm, mais j'ai pensé que vous pourriez aussi vous souhaitez encore plus de raisons précises pour lesquelles vous souhaitez structurer votre code de cette façon:
Il y a quelques questions ici. Tout d'abord, exactement là où vous économisez de cela? Vous dites SQL, mais est-ce un Serveur SQL server, une instance de SQL Express, un Cache de Données (SQL CE 3.5) ou de l'enregistrement par l'intermédiaire d'un Service Web pour parler à votre SERVEUR SQL server. Ces différentes sources de données différentes options de connectivité/exigences, et dans le cas de SQL CE qu'il y a quelques autres "pièges" du SQL lui-même.
Deuxièmement, êtes-vous sûr que vous voulez enregistrer les données dans une banque de données relationnelles telles que SQL Server? Considérez, vous pouvez utiliser XML, un fichier de données (texte, CSV. etc) ou même un binaire type de fichier à la place.
Puisque vous travaillez sur une application windows, vous avez un tas d'options sur où et comment enregistrer les données. Jusqu'à ce que vous savez où vous voulez placer les données, nous avions du mal à vous faire aider.
Je suis d'accord avec Mike Hofer. En gardant votre classe qui fait votre récupération et la persistance de l'objet séparé de classes de votre entreprise est la clé pour avoir un flexible et robuste. C'est le genre de code que vous souhaitez voir dans votre interface graphique ou la couche de gestion:
À l'intérieur de votre DALClass il devrait y avoir une méthode appelée InsertCustomers(IList clients) et il devrait avoir le code suivant:
Il est pénible d'écrire le DAL code à la main, mais vous aurez le plein contrôle de votre DAL, SQL et de la Cartographie du code et la modification de ceux-ci seront un jeu d'enfant dans l'avenir.
Si vous n'avez pas envie d'écrire tout le DAL Code à la main, vous pouvez obtenir un CodeGenerator comme Orasis Cartographie Studio pour générer exactement le même code sans écrire quoi que ce soit. Il vous suffit de créer votre SQL dans l'outil, la carte des propriétés pour les paramètres et vous avez terminé. Il va générer tout le reste pour vous.
Bonne chance et bonne DAL codage!
Je suis avec Stephen Wrighton. Il y a BEAUCOUP de variables ici, et beaucoup de questions sans réponse. Si c'est du SQL, est-il même un Microsoft dialecte SQL? Est-il Oracle? MySQL? Quelque chose d'autre?
En tout cas, ma préférence personnelle est d'éviter de construire SQL dans une application, si je peux, et d'appeler une procédure stockée, même pour les insertions et mises à jour. Puis je passe les arguments de la procédure à l'ADO.NET objet de commande. J'ai cette folle idée dans ma tête que SQL appartient dans la base de données. Peut-être ce qui vient de tout ce temps que j'ai passé le débogage terrifiant écrit le code ASP qui épissé des chaînes SQL ensemble de retour dans la Dot Com époque. (Jamais de nouveau.)
Si vous pensez qu'il est absolument nécessaire de le faire, de répondre à la Système.Texte.StringBuilder classe. L'apprendre. L'amour c'. Faire votre meilleur ami.
Mise à JOUR:
En voyant votre réponse, je vois maintenant que vous êtes travail avec SQL Server. Qui rend les choses beaucoup mieux.
Je voudrais vous recommandons de séparer votre code SQL dans une classe distincte, à l'écart de l'effectif de la classe affaires. Certains ne pourriez pas d'accord avec cela, mais il gardera le BUT des classes claires. (Voir La séparation des Préoccupations.)
Vous voulez avoir votre entreprise objet de la poignée de la logique métier, et une autre classe qui s'occupe des travaux de placer des données dans et hors de la base de données. De cette façon, si vous avez un problème avec la logique de sérialisation, vous avez une bien meilleure idée de où chercher, et vos chances de quittance de la logique d'affaires sont considérablement réduits. Il rend également votre application beaucoup plus facile à comprendre.
Un peu d'effort dans la rédaction d'un peu plus de classes est une ÉNORME récompense en bas de la route.
Mais c'est juste mon avis.
Je préfère l'idée de Mike Hofer, d'avoir une procédure Stockée dans le côté de SQL Server pour gérer les données mises à jour, et d'avoir une catégorie distincte pour encapsuler les appels à ceux stockés procs.
Juste mon 0.02$
Pas tout à fait sûr de ce que l'OP est de demander.
Vous devez définir exactement ce que vous faites dans le "Enregistrer" méthode
"Enregistrer" méthodes impliquent généralement que les deux cas sont traités par la procédure.
Une meilleure méthode serait d'avoir ("Créer" ou "Insérer") et ("mise à Jour" ou "Enregistrer") des méthodes.
Ou peut-être une procédure qui gère à la fois.