LINQ ORM Delphi (TMS / Devart)

[Schokohase]

Zitat:

Zitat von MyRealName (Beitrag 1426989)

Seine Lösung war eine neue DbVerbindung für jedes Fenser. :roll:

Die richtige Lösung heißt eigentlich pro ObjectManager eine eigene DbVerbindung und für jeden Kontext einen eigenen ObjectManager

[sakura]

Zitat:

Zitat von Union (Beitrag 1426994)

Leider läuft auch die interne Kommunikation C/S mit JSON. Daher eher für echte Multi-Tier Anwendungen geeignet.

Wieso sollte das nicht gehen? Wir nutzen es genau so, mit hunderten Clients ohne Probleme.

...:cat:...

[MyRealName]

Zitat:

Zitat von Schokohase (Beitrag 1426997)

Zitat:

Zitat von MyRealName (Beitrag 1426989)

Seine Lösung war eine neue DbVerbindung für jedes Fenser. :roll:

Die richtige Lösung heißt eigentlich pro ObjectManager eine eigene DbVerbindung und für jeden Kontext einen eigenen ObjectManager

Naja, jedes Fenster hatte in meinem Beispiel innerhalb dieser Diskussion einen eigenen ObjectManager. Aber da es eine MDI Anwendung ist im Netz, die von jedem Fenstertyp soviele Instanzen erstellen kann wie man wll, ist dies keien akzeptale Lösung, IMHO, da dies zu hunderten von Verbindungen führt. Besser wäre eine Transaction-Lösung, wo man eine DbVerbindung hat und jeder ObjectManager eine eigene Transaction besitzt.

[Schokohase]

Zitat:

Zitat von MyRealName (Beitrag 1427011)

Zitat:

Zitat von Schokohase (Beitrag 1426997)

Zitat:

Zitat von MyRealName (Beitrag 1426989)

Seine Lösung war eine neue DbVerbindung für jedes Fenser. :roll:

Die richtige Lösung heißt eigentlich pro ObjectManager eine eigene DbVerbindung und für jeden Kontext einen eigenen ObjectManager

Naja, jedes Fenster hatte in meinem Beispiel innerhalb dieser Diskussion einen eigenen ObjectManager. Aber da es eine MDI Anwendung ist im Netz, die von jedem Fenstertyp soviele Instanzen erstellen kann wie man wll, ist dies keien akzeptale Lösung, IMHO, da dies zu hunderten von Verbindungen führt. Besser wäre eine Transaction-Lösung, wo man eine DbVerbindung hat und jeder ObjectManager eine eigene Transaction besitzt.

Du hast da ein grundlegendes Problem im Design. Wenn du das Konzept umstellst, dann verschwinden auch deine Probleme.

- Daten holen:

ObjectManager nach EntityObject/en fragen.
Aus den EntityObject/en das BusinessObject erzeugen
ObjectManager wegwerfen.
Mit dem BusinessObject arbeiten.

- Daten schreiben:

ObjectManager nach EntityObject/en fragen.
EntityObject/e mit BusinessObject aktualisieren
ObjectManager Änderungen speichern
ObjectManager wegwerfen.

Jetzt mal so nachzählen: Wieviele ObjectManager haben wir so bei 50 MDI-Formularen geöffnet? IdR 0 (in Worten null) nur wenn etwas geladen oder gespeichert wird, dann sind die da und weil es für jede Aktion Lesen oder Schreiben einen eigenen ObjectManager gibt, kommen die sich auch nicht mit den Transaktionen ins Gehege.

[MyRealName]

Das problem ist ja aber, dass ich nicht eine komplett neue Anwendung schreibe, sondern schon 700.000 Zeilen Code habe ;) Und das ist alles basierend auf einem transaktionellen modell, wo die einzelnen Fenstern in einer eigenen Transaktion laufen.

Das umzubauen ist auch ziemlich heftig :p

[Schokohase]

Zitat:

Zitat von MyRealName (Beitrag 1427016)

Und das ist alles basierend auf einem transaktionellen modell, wo die einzelnen Fenstern in einer eigenen Transaktion laufen.

Das umzubauen ist auch ziemlich heftig :p

Das war aber so noch nie richtig, denn eine Transaktion sollte immer nur so lang wie nötig bestehen. Dieser Zeitraum liegt in der Praxis im Sekunden- oder sogar Millisekundenbereich.

Es ist allerdings etwas unfair wenn du hier die Schuld auf Aurelius schiebst, denn so hört sich deine Aussage dazu an.

[MyRealName]

Zitat:

Zitat von Schokohase (Beitrag 1427017)

Das war aber so noch nie richtig, denn eine Transaktion sollte immer nur so lang wie nötig bestehen. Dieser Zeitraum liegt in der Praxis im Sekunden- oder sogar Millisekundenbereich.

Das kann man nicht so pauschal sagen. Nimmt man den traditionellen Delphi Anatz, dann hat man TTable/TQuery Komponenten, die über ein TDataSource mit visuellen Komponenten verbunden sind.
Ist man da mit einer Interbase/Firebird Datenbank verbunden, geht es garnicht andrs als dass man über einen langen Zeitraum die Transaktion offen hat, denn sowie man sie schliesst, schliessen die Table/Queries auch.

Zitat:

Zitat von Schokohase (Beitrag 1427017)

Es ist allerdings etwas unfair wenn du hier die Schuld auf Aurelius schiebst, denn so hört sich deine Aussage dazu an.

Da hast Du eventuell recht, ich muss da mal drüber nachdenken, da dieses Modell ja keine aktive Transaktion braucht, es lädt ja alles in Object Listen.
Nichts desto trotz besteht die Gefahr die Kritik dass es nicht sauber gekapselt ist und man unter Umständen Sachen committed, die man noch garnicht schreiben will.

[Schokohase]

Zitat:

Zitat von MyRealName (Beitrag 1427072)

Zitat:

Zitat von Schokohase (Beitrag 1427017)

Das war aber so noch nie richtig, denn eine Transaktion sollte immer nur so lang wie nötig bestehen. Dieser Zeitraum liegt in der Praxis im Sekunden- oder sogar Millisekundenbereich.

Das kann man nicht so pauschal sagen. Nimmt man den traditionellen Delphi Anatz, dann hat man TTable/TQuery Komponenten, die über ein TDataSource mit visuellen Komponenten verbunden sind.
Ist man da mit einer Interbase/Firebird Datenbank verbunden, geht es garnicht andrs als dass man über einen langen Zeitraum die Transaktion offen hat, denn sowie man sie schliesst, schliessen die Table/Queries auch.

Doch kann man so pauschal sagen.

Zitat:

Ziel eines Transaktionssystems ist es stets, möglichst viele Transaktionen in möglichst kurzer Zeit abzuwickeln.

Quelle

Nur weil Emba das mit dem Rapid Application Development da etwas losgetreten hat, wird es nicht richtig. Man kann damit schnell mal was hinklatschen, aber dadurch hast du auch schon die Trennung zwischen UI, Logik und Persistenz nicht eingehalten. Also gleich mehrere Fehler auf einmal.

Die Rache kommt irgendwann später, aber sie kommt.

Natürlich funktioniert so ein Ansatz, aber er klebt halt wie Pech an deinen Händen.

[MyRealName]

Da kommen wir wieder zu dem zurück, wo ich sagte, dass die Anwendung ja schon da ist, schon seit Delphi 2 und ich bezweifle, das diese ORM Modelle damals schon gang und gäbe waren.

Nichts desto trotz sehe ich den ObjectManager eigentlich als meine Datenhalter an, der sich drum kümmert, meine aus der Datenbank geladenen Daten im Speicher zu halten.
Es würde ja auch nicht viel Sinn machen wenn :

Aurelius lädt Daten aus der DB
diese werden in Entities abgelegt
Ich lade die Entities dann in eigene Objecte, damt ich den ObjectManager freigeben kann
Ich arbeite dann mit meinen Objekten
und wenn ich Änderungen schreiben will, lade ich wieder die Entities aus der DB, ändere sie und schreibe sie zurück.

Da ist für mich 1 Kappe zuviel.
Die Entities sind ja direkt mit deiner GUI verbindbar und werden auf zuruf erst in die DB geschrieben (ObjectManager.Flush;). Solange ich dies nicht aufrufe sollte es möglich sein, an den objekten rumzufummeln, bis ich schwarz werde, oder ?

[Schokohase]

@MyRealName

Doch, genau so macht man das mit den Entitäten. Denn diese Entitäten sind die Datenbank-Tabellen als Klassen dargestellt. Und mit der Tabellen-Struktur löst man das Problem der Speicherung. Punkt.

Das Business-Objekt kann dabei schon wieder ganz anders aussehen.

Kleines Beispiel:

Wir haben einen Blog-Eintrag und jeder Benutzer diesen Beitrag bewerten.

Das Business-Objekt sieht so aus

Code:

BlogEntry
- Id
- Titel
- Body
- Rate (Bewertung des Benutzers)

Die Entity-Objekte (Tabellen) dazu sehen aber etwas anders aus

Code:

Blog
- Id
- Titel
- Body

BlogUserRate
- BlogId
- UserId
- Rate

denn wir wollen in den Tabellen die Bewertung von n Benutzern speichern können.

Wenn einem da also auch nichts auf die Füße fallen soll, dann trennt man ganz brav zwischen Business-Layer und Daten-Layer.

Zitat:

Zitat von MyRealName (Beitrag 1427096)

Da kommen wir wieder zu dem zurück, wo ich sagte, dass die Anwendung ja schon da ist, schon seit Delphi 2 und ich bezweifle, das diese ORM Modelle damals schon gang und gäbe waren.

Das mag schon sein, aber die Zeit der Holzräder und Kutschen ist auch gottlob vorbei und wir wünschen uns diese Zeit des Reisens auch nicht mehr zurück. Wir haben da jetzt etwas Besseres (Luftreifen und Luftfederung).