O/R Mapper und Codegeneratoren
verwendetes Datenbanksystem: <SQL Server, Access>
Hallo zusammen,
ich möchte die Arbeit in der Programmierung mittels aktueller Techniken etwas vereinfachen. Dazu habe ich mir einiges an OR Mappern und Codegeneratoren
im Internet angeschaut, werde aber förmlich an Infos erschlagen und kann unmöglich alles testen. 🤔
Welche Tools und/oder Techniken bringen wirklich was?
Die Idee ist entweder aus einer Datenbank eine Anwendung zu generieren.
dazu hab ich das Tool NextGeneration gefunden. Wird getestet.
Die Idee erst per UML Klasen(Entities) zu entwickeln und dann daraus
Code zu generieren scheint mit mit objectIF sehr gut zu funktionieren,
zumal das Tool kostenlos ist für den Personal Bereich und überdies sehr gut mit VS2008 zusammen arbeitet.
Zu OR Mappern wird man totgeschlagen.
- MyGeneration mit doodads
- Entity Spaces,Nhibernate, gentle u.a.
- Entity Framework von Microsoft
- Linq to SQL, To Entities und weiss der Deiwel
Welche Techniken soll man hier präferieren, welche haben sich durchgesetzt oder werden sich durchsetzen.
Lohnen sich OR mapper von 3 Anbietternoder oder bietet Entity Framework mehr ?
Was ist mit Linq ? Bietet ADO.Net nicht genug?
Ich komm vor lauter Infos nicht dazu auch nur 1 Codezeile zu entwickeln... X(
Was wendet ihr an, womit habt ihr die besten Erfahrungen gemacht.
Gruß
„Wenn man eine Katze auseinandernehmen will, um zu sehen, wie sie funktioniert, hat man als erstes eine nicht funktionierende Katze in den Händen.“
Hallo,
ich arbeite mittlerweile bei allen Daten-gebundenen Projekten mit dem Entity Framework und fahre damit auch sehr gut - verwende aber mittlerweile die noch nicht offizielle 4.2 Version mit Untersützung von ENums, Local Cache, Compiled Queries......Ich erstelle meine Entities mittels Designer und dann via DbContext Generator lass ich mir die entsprechenden POCOs generieren.
Große Konkurrenz gibt es mit NHibernate; hab ich aber am Anfang keine guten Erfahrungen gemacht und dann nicht mehr verfolgt. Kann dazu also keine aktuelle Aussage machen.
LINQ ist ein wunderbares Mittel und möglichst performant interne Abfragen abzusenden, anstatt auf Schleifen o.ä. setzen zu müssen. Beim EF werd dieses auf dem SQL Server ausgeführt; aus Entwicklersicht aber alles schön und sicher mit C#.
ADO.NET ist hier im Hintergrund und kümmert sich um die Verbindung etc.
Ich muss dazu aber sagen, dass ich im Web-Umfeld zu Hause bin; und hier ist das EF sehr verflochten. Ratsam es an dieser Stelle zu verwenden.
Mit Access kann es aber nicht so gut.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Was ist denn mit LightSwitch? Das kann doch auch aus einer Datenbank eine Anwendung generieren und arbeitet mit dem Entity Framework.
q.e.d.
Das Entity Framework scheint mir auch das aktuell
am meisten verfolgte Thema zu sein, wenn man die Anzahl
der verfügbaren oder aktuell geschriebenen Bücher dazu sieht.
Mit NHibernate habe ich erste Erfahrungen gemacht,
war aber aufgrund der recht komplexen Vorgehensweise
wie xml Dateien und Einbindung diverser dll, die versionsabhängig sind
erst mal nicht so angetan. habe Wochen gebraucht, bis ich ein lauffähiges
Projekt unter SQL Server hatte, da aktuelle Versionenn nicht mit alten projekten
zusammen arbeiten wollten. Zudem nur Onlinetutorials und veraltete Literatur.
Habe gerade NextGeneration getestet. Erzeugt aufgrund einer bestehenden SQL Server DB Unmengen an Code und etliche Projekte. Die muss man dann händisch in den WinForms verwurschteln ? Werde jetzt mal schauen, was da genau geschieht. Das Tool generiert DataAdapter, DataSets und Service sowie Basisklassen. Mal schauen...
oder mal lightSwitsch anschauen 🤔
„Wenn man eine Katze auseinandernehmen will, um zu sehen, wie sie funktioniert, hat man als erstes eine nicht funktionierende Katze in den Händen.“
Ich komm vor lauter Infos nicht dazu auch nur 1 Codezeile zu entwickeln... X(
Ja - das ist die Kehrseite von so viel Vereinfachung 😁
Die Idee ist entweder aus einer Datenbank eine Anwendung zu generieren.
Das geht dann schon deutlich über einen O/R-Mapper hinaus.
Dieser erzeugt im Normalfall erstmal nur Klassen zum DB-Zugriff, aber keinerlei UI-Code etc.
Derartigen Generatoren stehe ich eher skeptisch gegenüber.
Bietet ADO.Net nicht genug?
"Klassische" O/R-Mapper ermöglichen dir salopp ausgedrückt, mit einer relationalen DB wie mit einer Objektdatenbank zu arbeiten.
Somit kannst du dann z.B. direkt im Code schreiben:
var bestCustomers = context.Customers.OrderBy(c => c.Oders.Sum(o => o.Total)).Take(10).ToArray();
Du kommst nicht mehr direkt mit SQL oder mit DataSets in Kontakt - Relationen, Mappings etc. übernimmt der O/R Mapper.
O/R-Mapper sind also quasi die nächste "Stufe" nach den typisierten Datensets von ADO.NET.
Die zusätzliche Abstraktion kann dabei sowohl positiv sein (keinerlei Hantierung mehr mit DataSets, SqlCommands etc.), aber auch negativ: Teilweise generiert so ein O/R-Mapper ziemlich grauenhaftes SQL bzw. man merkt gar nicht, wie ineffizient man etwas abfragt.
Linq2Sql würde ich nicht mehr verwenden - das ist irgendwie schon halbtod und unterstützt nur den SQL-Server von MS.
Dann eher das EF - dafür existieren auch Provider für MySQL etc. (auch wenn ich die persönlich noch nicht im Einsatz hatte).
Erzeuge einfach mal eine Datenbank (oder verwende eine bestehende), füge ein Entity Data Model dafür in deine Anwendung hinzu und spiele mit diesem etwas herum.
Dann solltest du schnell sehen, ob und wenn ja was ein O/R-Mapper für dich bringt.
Wollte mal in LightWitch reinschauen.
Das scheint mir sowas zu sein wie NewGeneration - halt nur von Microsoft?
Zudem scheint das Tool erst ab VS2010 integriert zu sein?
Wenn man so im google schaut, scheint die Tendenz nahe zu liegen das das Entity Framework "fast" nur Vorteile ggüber Linq hat. kann es sein dass Linq ein Hype war und so allmählich dahingeht?Ich frage mich sowieso, warum Microsoft 2 parallel laufende Techniken entwickelt. Aber linq scheint ja auch fertig bzw. wird nicht mehr viel dran gemacht. Hat sich offenbar nicht behaupten können...
Zumal Linq ja irgendwie SQL generiert und an den SQL Server weiterreicht, was so ziemlich unperformant sein dürfte. Stored procedures werden ja direkt vom SQL Server in Maschinencode übersetzt und sind ziemlich schnell. Somit dürften Linq Anwendungen, die mit großen Datenbeständen, Joins und Subselects arbeiten aus Performance gründen eher ausscheiden? Vorteilhaft ist halt nur die Syntaxprüfung.
„Wenn man eine Katze auseinandernehmen will, um zu sehen, wie sie funktioniert, hat man als erstes eine nicht funktionierende Katze in den Händen.“
Zumal Linq ja irgendwie SQL generiert und an den SQL Server weiterreicht, was so ziemlich unperformant sein dürfte.
Du bringst da einiges durcheinander.
Zum einen: Es gibt nicht "LINQ" - es gibt LinqToObjects, LinqToXml und eben LinqToSql sowie LinqToEntities.
Die ersten beiden Technologien haben quasi nichts mit Datenbanken und O/R-Mappern zu tun.
LinqToSql und LinqToEntities sind zwei unabhängige, aber sehr ähnliche O/R-Mapper.
Dabei ist mit LinqToEntities das EF gemeint, während LinqToSql quasi ein "EF light" darstellt (weniger Support für Vererbung, nur Support für MS-SQL-Server, etc.).
LinqToSql ist dem EF daher unterlegen, bietet aber im Vergleich dazu keine wirklichen Vorteile - die Syntax ist sogar sehr ähnlich.
Meine Vermutung, warum es überhaupt die beiden Technologien gibt, ist, dass LinqToEntities (also das EF) nicht rechtzeitig fertig wurde und daher LinqToSql vorgeschoben wurde.
Aber die Technik hinter LinqToSql / dem EF ist die gleiche: Es werden anhand des DB-Schemas Klassen generiert und bei Queries aus ExpressionTrees SQL-Abfragen erzeugt.
Die Performance des EF ist sogar noch erstaunlich hoch für das, was es leistet. So cacht der SQL Server beispielsweise auch "normale" Queries. Zudem kann man auch StoredProcedures und Views aus dem EF ansprechen.
Wenn Performance eine zentrale Rolle spielt, kannst du ja auch nochmal nach Vergleichen googeln oder eigene Messungen anstellen.
LightSwitch ist eher ein Anwendungsgenerator. Aus einer bestehenden Datenbank generiert dieses Tool eine Business Anwendung mit 3-Schichten-Architektur. Die UI basiert auf SilverLight und die Datenzugriffsschicht auf dem Entity Framework. Zusätzliche Geschäftslogik kann man dann in C# hinzuprogrammieren.
Ich kenne Entwickler, die darauf schwören. Ein befreundeter Entwickler erzählte mir mal, dass sie mit LightSwitch eine Software, für die 1 Jahr Aufwand geplant war, innerhalb von 2-3 Monaten zurechtgeschustert und dem Kunden ausgeliefert haben.
q.e.d.
@Winsharp93
es kann natürlich gut möglich sein, dass Microsoft
Linq To SQL rausgebracht hat, weil das EF noch nicht fertig war.
Im Netz gibts ne Bachelorarbeit, die NHibernate, EF und Genome vergleicht,
wobei aktuell immer noch NHibernate die besten Karten zugespielt werden, da EF
Unmengen schwer zu durchdringenden Code erzeugt.
@programmiertroll
genau das ist der Grund warum ich mich damit beschäftige.
Mit dem Nextgeneration Tool oder auch mit LightSwitch lassen sich
auf Basis bestehender Datenbanken im Handumdrehen ganze Anwendungen in 3 Schicht Arichitektur erstellen. Anders kann man wohl zukünftig auch kein Geld mehr verdienen. Der Ostblock und die Inder sind eh schneller, vor allem billiger.
Und selbst die nutzen wahrscheinlich solche Tools 😉
das einzige was die nicht haben ist das Fachwissen zu dem Thema zu dem sie eine Applikation schreiben.
Gibts LightSwitch denn auch schon für VS2008 ?
„Wenn man eine Katze auseinandernehmen will, um zu sehen, wie sie funktioniert, hat man als erstes eine nicht funktionierende Katze in den Händen.“
Hallo zusammen,
ich habe eine Zeit lang mit EF gearbeitet , danach EF 4.1 wegen dem Code First Ansatz.
Da wir nicht nur gegen MSSQL Datenbanken programmieren und der Code First bisher nur mit MSSQL funktioniert hat (korrigiert mich wenn ich mich irre), bin ich recht schnell zu nHibernate gewandert bzw. zu fluentnHibernate.
Vorteil ist, du musst eben keine XML Dateien fürs Mapping schreiben, du kannst alles im Code erledigen !
Linq ist genauso nutzbar wie unterschiedliche Context, Lazy Loading etc.
Grüße
Hallo!
Arbeite Hauptsächlich mit Microsoft SQL Server 2008 und Windows-Forms Anwendungen und habe vor kurzem auf EF 4.1 umgestellt und bin hellauf begeistert! (nHibernate gewandert bzw. zu fluentnHibernate sagen mir aber nichts)
lg myGil
Hallo
wir arbeiten seit ca 3 jahren mit nhibernate. bin mehr als zufrieden. habe noch nichts angetroffen was nhibernate nicht kann. was mir besonders gefällt ist die möglichkeit eigene typen zu definieren.
zu sagen ist, dass nhibernate bei uns teil eines frameworkes ist, mit welchem wir schnell und effizient kundenspezfische software schreiben.
wir definieren darin die objekte im hbm.xml und selbstentwickelte generatoren generieren daraus die DTOs, views, controllers, service-interfaces, basis-service-implementationen usw.
klappt wunderbar
Hallo,
ich arbeite ebenfalls seit sehr langer Zeit mit NHibernate. Neben den eigenen Datentypen die HappyLil angesprochen hat, ist ein riesen Feature von NH, das man NH Linq mit eigenen Funktionen erweitern kann und auf z.B. Stored Functions mappen kann.
"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)