vb@rchiv
VB Classic
VB.NET
ADO.NET
VBA
C#
 TOP-Angebot: 17 bzw. 24 Entwickler-Vollversionen zum unschlagbaren Preis!  
 vb@rchiv Quick-Search: Suche startenErweiterte Suche starten   Impressum  | Datenschutz  | vb@rchiv CD Vol.6  | Shop Copyright ©2000-2024
 
zurück

 Sie sind aktuell nicht angemeldet.Funktionen: Einloggen  |  Neu registrieren  |  Suchen

VB.NET - Ein- und Umsteiger
Re: MFC oder doch Code in den Windows-Forms? 
Autor: Zero-G.
Datum: 09.09.10 14:43
Jetzt weiß ich wieder, warum ich in den letzten 2 Jahren lieber im MS-Forum für VB unterwegs war...

Zitat:


1) Natürlich kann man ADO.NET auch gegen Sql-Injection schützen, dafür gibt es die ParameterCollection, und wenn man sich einen vernünftigen DAL macht, stehen die SQL Anweisungen auch nicht wild im Code.

Geb ich Dir recht. - Hab mich dabei schlecht ausgedrückt, weil ich meinte, dass der vom Designer generierte Code nicht vor Injections schützt.

Zu 2. Ich habe nie behauptet, dass LinQ / LinQ to SQL ist. - Ich habe es in diesem Fall abgekürzt, weil es hier eindeutig über die Frage zu Datenbanken geht. - & wenn Du den Schluss meiner Aussage gelesen hättest, habe ich explizit darauf hingewiesen, dass es verschiedene LinQ to ... gibt. Aber wenn man im Google mal LinQ eingibt, kommt man auf gute Referenzen.

Zu Punkt 3 finde ich Deine Aussage sehr interessant. - Wenn Du der Meinung bist, dass XPO niemand kennt & NHibernate viel mehr Leute kennen. - OK ... -> Ohne Worte ...
Muss aber wieder fairer weise zugeben auf's Offensichtliche hab ich vergessen gehabt, wie von Dir erwähnt: Entity Framework.

Zitat:


Wenn du solche Grundsätzlichen Aussagen machen möchtest, solltest Du also erstmal kontrollieren ob Du auch wirklich verstanden hast wovon Du redest.


Von Deinen perösnlichen Angriffen bist Du nach wie vor so arrogant wie früher. - Interessant...

Du hattest genug Zeit Froggy eine von Dir qualifizierte Aussage zu geben. - Hast Du nicht gemacht. - & die 2. Antwort von Dir, ist sicher auch sehr hilfreich für Froggy damit er sich besser auskennt.

Versuch mal von Deinem Rösslein runter zu kommen & Dir die die Frage von Froggy mal GENAU durch zu lesen. - Er will, dass ihm jemand Möglichkeiten aufzeigt, wie er ein Problem lösen kann & wenn die nicht 100%ig Deinem Einverständnis gefallen, weil vielleicht nicht ganz korrekt, dann auch gut. - Aber ich behaupte hier mal dass meine "falsche" Aussage ihm mehr hilft als Deine.
alle Nachrichten anzeigenGesamtübersicht  |  Zum Thema  |  Suchen

 ThemaViews  AutorDatum
MFC oder doch Code in den Windows-Forms?2.213Froggy08.09.10 18:36
Re: MFC oder doch Code in den Windows-Forms?1.635Zero-G.09.09.10 14:04
Re: MFC oder doch Code in den Windows-Forms?1.523ModeratorFZelle09.09.10 14:16
Re: MFC oder doch Code in den Windows-Forms?1.486ModeratorFZelle09.09.10 14:23
Re: MFC oder doch Code in den Windows-Forms?1.626Froggy09.09.10 14:46
Re: MFC oder doch Code in den Windows-Forms?1.505Zero-G.09.09.10 14:43
Re: MFC oder doch Code in den Windows-Forms?1.510ModeratorFZelle09.09.10 16:21
Re: MFC oder doch Code in den Windows-Forms?1.520ModeratorRalfE09.09.10 15:30
Re: MFC oder doch Code in den Windows-Forms?1.445Froggy09.09.10 18:00
Re: MFC oder doch Code in den Windows-Forms?1.630Zero-G.09.09.10 18:14
Re: MFC oder doch Code in den Windows-Forms?1.496Froggy09.09.10 18:34
Re: MFC oder doch Code in den Windows-Forms?1.935ModeratorRalfE09.09.10 18:56
Re: MFC oder doch Code in den Windows-Forms?1.522Froggy09.09.10 19:16
Re: MFC oder doch Code in den Windows-Forms?1.550ModeratorRalfE09.09.10 19:34
Re: MFC oder doch Code in den Windows-Forms?1.468Froggy09.09.10 22:13
Re: MFC oder doch Code in den Windows-Forms?1.485ModeratorFZelle10.09.10 10:00

Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.

Einloggen  |  Neu registrieren

Funktionen:  Zum Thema  |  GesamtübersichtSuchen 

nach obenzurück
  
   

Copyright ©2000-2024 vb@rchiv Dieter Otter
Alle Rechte vorbehalten.
Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.

Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel