Laden...

Entity Framework, DDD, NHibernate

Erstellt von susisorglos vor 6 Jahren Letzter Beitrag vor 6 Jahren 1.951 Views
susisorglos Themenstarter:in
43 Beiträge seit 2008
vor 6 Jahren
Entity Framework, DDD, NHibernate

Ich greife mit einem ConnectionString auf eine FoxPro Datenbank zu.
In einer anderen Systemsprache habe ich eine Lösung gefunden.
(JavaFX DaoFactory)

Nun schwirrt mir der Kopf beim Einstieg in die Materie unter VS 2017.
Gibt es hier Anwender/Entwickler oder evtl. Infos/Links
über die Machbarkeit von Datenkapselung mit Hilfe
von Entity FW, Domain Driven Design oder NHibernate?

Ich bin für jede Anregung dankbar.
Bevor ich mich evtl. für die falsche Entscheidung zu früh frei mache,
lasse ich mich gern noch zum Nachdenken anregen.
Gruss susi

VS 2017 Community

P
1.090 Beiträge seit 2011
vor 6 Jahren

Meines Wissens gibt es für EF keinen Provider für FoxPro.

Du könntest das Repository Pattern verwenden um den Datenzugrif zu kapseln.
Wenn du hier gegen ein Interfache Implementierst, kannst du bei bedarf "einfach" den Datenzugriff ändern.

Und eine 3-Schichten-Architektur.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

D
985 Beiträge seit 2014
vor 6 Jahren

... von Entity FW, Domain Driven Design oder NHibernate?

... Apfel, Quantenphysik oder Birne?

Entity FW => ORM
NHibernate => ORM
DDD => nicht ORM

C
26 Beiträge seit 2016
vor 6 Jahren

Es sei mal dahingestellt, ob es Sinn macht noch mit FoxPro zu arbeiten. 🤔
Vielleicht solltest Du über eine Datenmigration nachdenken?

Es gibt wohl einen EF-Provider:
https://github.com/tombrothers/VfpEntityFrameworkProvider2
Wenn EF also ein Must-Have ist, wäre das ein Versuch wert.

Ansonsten könnte man noch kommerzielle Produkte wie DevArt DotConnect & Entity-Developer evaluieren.

Ich würde Dapper den Vorzug geben, da dies mit jedem ADO.NET-Provider funktioniert:

Dapper has no DB specific implementation details, it works across all .NET ADO providers including SQLite, SQL CE, Firebird, Oracle, MySQL, PostgreSQL and SQL Server.

Dapper ist sehr einfach zu implementieren und wesentlich schneller als EF.

16.834 Beiträge seit 2008
vor 6 Jahren

Dazu sei gesagt, dass Dapper nur ein Micro ORM und kein vollständiger ORM ist.
Dapper ist schneller, weil es z.B. keinerlei Unterstützung beim Schreiben von SQL Queries anbietet, was die meiste Ausführungszeit kostet, sondern dies zurück in die Verantwortung des Entwicklers gibt (was manche auch wollen).

susisorglos Themenstarter:in
43 Beiträge seit 2008
vor 6 Jahren

@Sir Rufo
DDD - kein ORM
Vielen Dank für die Eingrenzung.

@codesoldier
Die Datenmigration ist im Plan.

susi

VS 2017 Community

susisorglos Themenstarter:in
43 Beiträge seit 2008
vor 6 Jahren

@codesoldier

Schönes Anwendungsbeispiel

Author: Khodor Shahimi
alle 9 Teile veröffentlicht am 22.03.2017

https://www.youtube.com/watch?v=_9d78xRic6s
C# Dapper and DevExpress Full Sample Part 1 - Part 9

Ps: Schichten/Kapselung habe ich hier noch nicht getestet

susi

VS 2017 Community