AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken LINQ ORM Delphi (TMS / Devart)

LINQ ORM Delphi (TMS / Devart)

Ein Thema von taveuni · begonnen am 5. Mär 2019 · letzter Beitrag vom 13. Mär 2019
Antwort Antwort
Seite 2 von 3     12 3   
Schokohase
(Gast)

n/a Beiträge
 
#11

AW: LINQ ORM Delphi (TMS / Devart)

  Alt 5. Mär 2019, 15:16
Seine Lösung war eine neue DbVerbindung für jedes Fenser.
Die richtige Lösung heißt eigentlich pro ObjectManager eine eigene DbVerbindung und für jeden Kontext einen eigenen ObjectManager
  Mit Zitat antworten Zitat
Benutzerbild von sakura
sakura

Registriert seit: 10. Jun 2002
Ort: München
11.412 Beiträge
 
Delphi 11 Alexandria
 
#12

AW: LINQ ORM Delphi (TMS / Devart)

  Alt 5. Mär 2019, 15:54
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.

......
Daniel W.
Ich bin nicht zurück, ich tue nur so
  Mit Zitat antworten Zitat
Benutzerbild von MyRealName
MyRealName

Registriert seit: 19. Okt 2003
Ort: Heilbronn
673 Beiträge
 
Delphi 10.4 Sydney
 
#13

AW: LINQ ORM Delphi (TMS / Devart)

  Alt 5. Mär 2019, 20:25
Seine Lösung war eine neue DbVerbindung für jedes Fenser.
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.
  Mit Zitat antworten Zitat
Schokohase
(Gast)

n/a Beiträge
 
#14

AW: LINQ ORM Delphi (TMS / Devart)

  Alt 5. Mär 2019, 21:11
Seine Lösung war eine neue DbVerbindung für jedes Fenser.
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.

Geändert von Schokohase ( 5. Mär 2019 um 21:13 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von MyRealName
MyRealName

Registriert seit: 19. Okt 2003
Ort: Heilbronn
673 Beiträge
 
Delphi 10.4 Sydney
 
#15

AW: LINQ ORM Delphi (TMS / Devart)

  Alt 5. Mär 2019, 22:33
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
  Mit Zitat antworten Zitat
Schokohase
(Gast)

n/a Beiträge
 
#16

AW: LINQ ORM Delphi (TMS / Devart)

  Alt 5. Mär 2019, 23:04
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.
  Mit Zitat antworten Zitat
Benutzerbild von MyRealName
MyRealName

Registriert seit: 19. Okt 2003
Ort: Heilbronn
673 Beiträge
 
Delphi 10.4 Sydney
 
#17

AW: LINQ ORM Delphi (TMS / Devart)

  Alt 6. Mär 2019, 14:27

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.

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.
  Mit Zitat antworten Zitat
Schokohase
(Gast)

n/a Beiträge
 
#18

AW: LINQ ORM Delphi (TMS / Devart)

  Alt 6. Mär 2019, 14:41

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.
  Mit Zitat antworten Zitat
Benutzerbild von MyRealName
MyRealName

Registriert seit: 19. Okt 2003
Ort: Heilbronn
673 Beiträge
 
Delphi 10.4 Sydney
 
#19

AW: LINQ ORM Delphi (TMS / Devart)

  Alt 6. Mär 2019, 16:47
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 ?
  Mit Zitat antworten Zitat
Schokohase
(Gast)

n/a Beiträge
 
#20

AW: LINQ ORM Delphi (TMS / Devart)

  Alt 6. Mär 2019, 17:29
@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.

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).

Geändert von Schokohase ( 6. Mär 2019 um 17:39 Uhr)
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:32 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz