Laden...

Wann keinen ORM Mapper verwenden?

Erstellt von winmike vor 13 Jahren Letzter Beitrag vor 13 Jahren 2.881 Views
winmike Themenstarter:in
173 Beiträge seit 2009
vor 13 Jahren
Wann keinen ORM Mapper verwenden?

Hallo

Ich arbeite gerade an einer neuen Applikation - under the hood - ne klassische Applikation welche halt Daten anzeigt / einfügt / ändert.

Da mir Ado.net Entity Framework 4 mit POCO Change Tracking ein Rätsel ist (es gibt Fälle wo es nicht geht und ich keine Erklärung finde) wollte ich fragen, ab wann man den Amazon weg ("no frameworks") gehen soll und die klassischen Pattern von Martin Fowler nimmt

Danke
LG

3.511 Beiträge seit 2005
vor 13 Jahren

Hallo,

Ich arbeite gerade an einer neuen Applikation - under the hood - ne klassische Applikation welche halt Daten anzeigt / einfügt / ändert.

Wenn es ein reiner Fat Client ist, dann würde ich ohne zu zögern auf einen O/R Mapper setzen (bir mir hat das Rennen allerdings (Fluent)NHibernate gewonnen).

Allerdings haben O/R Mapper bei komplexeren Aufgaben auch ihre Grenzen (z.B. Reporting). Man kann aber immer eigenes SQL reinfeuern.

Bei verteilten Anwendungen müsste man sich genau überlegen, ob ein O/R Mapper lohnt. Ebenfalls sollte man bei der Überlegung mit einbeziehen, das zwar O/R Mapper mittlerweile sehr saubere Statements generieren (NHibernate), aber man mit manuell gebastelten SQL doch hier und da noch Performance rauszuholen kann. Wobei bei Fat Clients das eigentlich ausser acht gelassen werden kann.

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

2.187 Beiträge seit 2005
vor 13 Jahren

Hallo winmike,

Gegen ORMapper fällt mir noch ein Grund ein:
Wenn die Datenstruktur nicht bekannt ist und/oder sich mehr als schnell ändert.

Gruß
Juy Juka

3.511 Beiträge seit 2005
vor 13 Jahren

Wobei man selbst das mit NHibernate erschlagen kann. Wenn man ein Metadaten-Modell mitpflegt, kann NHibernate auch damit umgehen. Dann wird es allerdings kompliziert. Aber es geht.

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

M
153 Beiträge seit 2010
vor 13 Jahren

Also verteilte Software, das wäre mir als Grund gegen einen O/R-Mapper zu wenig.

Die folgenden Fälle eignen sich aus meiner Sicht nicht für O/R-Mapping:
*Massendatenoperationen *Mehrere Projekte untereinander die nicht verbunden sind und die alle auf dieselbe Datenbank zugreifen *Triviale Lösungen *Spezielle Anforderungen an das SQL, wie Locking-Optimierung oder Volltextsuche

winmike Themenstarter:in
173 Beiträge seit 2009
vor 13 Jahren

Hi

Das Datenmodell ist bekannt und ich behaupte mal, dass es sich nicht so schnell ändern wird (wenn korrekt erfasst wurde).

Die Fragen die mich noch quälen:
* Ich weiß von einer extrem großen Firma, dass die auf ORM verzichten und eine eigene DB Group haben die das implementiert und auf Herz und Nieren testet (es handelt sich um kritischen Environment)
* Die Testbarkeit von ORM ist schwierig da es extrem viel abstrahiert (z.B. lustige Exeption die nach dem 3. Datensatz halt mal kommen - man ist halt im Framework eingesperrt - das betrifft auch: man muss Sachen so umsetzen wie das Framework es will)
* Andererseits schreibt Fowler auch: Ich habe eine Klasse Person die eine List<Briefmarken> hat. Wenn ich jetzt die Person clientseitig bearbeite, muss ich eine Menge Mehrarbeit leisten (Changetracking auf List<Briefmarke>)
* NHibernate hab ich schon benutzt - allerdings musste ich die DTOs händisch mappen, bevor ich sie über WCF geschickt hab. Hat sich das geändert inzwischen?

Danke
LG

161 Beiträge seit 2007
vor 13 Jahren

* NHibernate hab ich schon benutzt - allerdings musste ich die DTOs händisch mappen, bevor ich sie über WCF geschickt hab. Hat sich das geändert inzwischen?

Für diese konkrete Problem würd ich mir mal den AutoMapper anschauen.

Was die Frage ORM oder nicht angeht, würde ich zuerst mal prüfen ob es eine SQL-Datenbank sein muss. Wenn ja, spricht eigentlich wenig dagegen. Für komplexe Abfragen kann man sich eine Query-Db erstellen und für Volltextsuche gäbe es Lucene.Net.

Das ist jetzt natürlich sehr sehr alg. gesprochen ohne die konkrete Aufgabenstellung zu kennen.

"Eine wirklich gute Idee erkennt man daran,
dass ihre Verwirklichung von vorneherein ausgeschlossen erscheint."
(Albert Einstein)

Gelöschter Account
vor 13 Jahren

Ich weiß von einer extrem großen Firma, dass die auf ORM verzichten und eine eigene DB Group haben die das implementiert und auf Herz und Nieren testet

gegenargument. ich weiß auch von einer extrem großen firma, die auch eine eigene datenbank macht, weil sie davon überzeugt sind und es ist eine einzige katastophe.
ich bin sogar der meinung das die mit einer csv datei besser drann wären als mit dem kranken monster, das die produziert haben.

die kernaussage ist: schau dir an was du genau brauchst. wenn es etwas gibt, das dir alle anforderungen erfüllt.... dann nimm es und sei glücklich es nciht selbst machen zu müssen.

bei so sachen wie nhibernate kommt noch der vorteil, das es eine starke community gibt, die mit viel erfahrung helfen kann und das nhibernate schon tausende male bis ins kleinste getestet ist, da es relativ häufig verwendung hat.

wenn du etwas client- und serverseitig amchen willst, so lohnt sich auch openaccess. das ist auch ein .net orm, das jedoch container unterstützt, welche sich serialisieren lassen und die alle änderungen im container tracken um sie nachher bei einem serverseitigen sync korrekt in die datenbank spielen zu können.

1.564 Beiträge seit 2007
vor 13 Jahren

Hallo winmike

Du kannst ORMs verwenden. Solange diese POCOs unterstützen kannst du den ORM durchaus auch in einem großen Projekt verwenden.

Wichtig ist mir hierbei nur, dass der ORM im Data Access Layer weggekapselt ist. Die Applikation kann ruhig von der automatischen Generierung von SQL Statements profitieren. Allerdings sollte weder der Business Logic Layer noch der Presentation Layer wirklich wissen dass da ein ORM drunterliegt. Damit ist dann auch die Testbarkeit recht gut gegeben. Wenn die ganze Datenschicht über Interfaces zur Verfügung gestellt wird kannst du hier für Unit Tests recht schick Mock-Objekte einschieben.

Allerdings gibt es immer Anwendungsfälle bei denen ORMs der falsche Weg sind. Siehe hierfür beispielsweise die Liste von mg.net.

Grüße
Flo

Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+

Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.

winmike Themenstarter:in
173 Beiträge seit 2009
vor 13 Jahren

Ok Danke für die zahlreichen Antworten. Hoffe EF 4 Bücher kommen bald und bringen Licht ins Dunkle 😉

winmike Themenstarter:in
173 Beiträge seit 2009
vor 13 Jahren

@JAck30lena: OpenAccess scheint wirklich cool zu sein - aber leider halt auch nicht billig - bin Volunteer 😉

906 Beiträge seit 2005
vor 13 Jahren

welche Datenbank nutzt du? Die Express Editions (SQL Express, Orcale Express) und freie Datenbanken (MySQL und Firebird) kannst du mit der kostenlosen Version OpenAccess ORM Express für lau nutzen:

http://www.telerik.com/community/free-products.aspx

winmike Themenstarter:in
173 Beiträge seit 2009
vor 13 Jahren

@MagicAndre1981: Puh übersehen - thx!! Werde noch mal checken ob ich auch mit SQL Express auskomme

F
10.010 Beiträge seit 2004
vor 13 Jahren

SqlExress 2008 R2 hat die DB Begrenzung auf 10GB ( pro Datenbank ) hochgesetzt.