Richtig eine Database Connection erstellen und Cachen?

Hallo lieber User,

ich arbeite gerade an einer web api umd Endpoints für eine Angluar App bereit zu stellen.
Nun ist es soweit das ich eine Verbindung zur Datenbank herstellen muss und das ganze richtig Aufbaue.

Ich habe zuerst an das repository pattern gedacht aber nachdem ich diese beiden Blogs gelesen habe bin ich mir da nicht mehr so sicher da einer der Gründe ist das man nur mehr abstracte Layer hat die wohl nicht benötigt werden.

Das sind die beiden Blogs falls jemand Interesse hat diese zu lesen:
Ditch the repository pattern
Avoid repository pattern

Mein datenbankschmea ist relativ komplex und ich dachte schon daran einfach nur den DB-Conntext zu nutzen und alles in einer InMermory Database zu speichern, bin mir aber unsicher dabei.

Hat Jemand Erfahrung oder Tipps?

Hallo Olii,

der DbContext hat erstmal nichts mit einer InMemory-DB zu tun. Er ist mehr eine Abstrahierung und bietet ein Unit of Work. Wo die Datenbank dann läuft ist abhängig von der Datenbank. Das kann eine InMemory-DB sein, aber auch eine MSSQL, etc.

Eine Datenbankverbindung sollte pro Request gemacht und danach wieder zugemacht werden. Dein Server sollte keine Verbindungen offen halten oder dergleichen.

Gruss

Coffeebean

Hallo
ich habe mal den zweiten Blog überflogen und bin nicht der Meinung des Autors. Er sagt grob dass man konkrete Repositories baut um optimale Suchanfragen erstellen zu können. Im Beispiel war FindAuthorByCountry(), eine Methode im Repository die weiß wie man mit effizienter Anfrage Autoren gefiltert ausliest. Das ist aber problemlos mit generischen Repositories mglich die ein Queryable<TEntity>-Schnittstelle anbieten.
Was ich sagen will: nimm dir die Artikel nicht zu sehr zu Herzen.

Hi Olii,

du solltest vielleicht erst mal schauen ob Caching nötig und sinnvoll ist.

Zum Thema Caching findend man einiges im Internet.

Hier z.B. mal von stackoverflow.
Es gibt da sehr unterschiedliche Strategien.

Caching würde erst Sinn machen, wenn du Performance Probleme beim Abfragen deiner Daten hast.
Hast du den hier irgendwelche gemessene Performance Probleme?

Wenn du deine DB wirklich am Optimum fährst, also auf der Seite nicht mehr durch korrekte Indizierung o.ä. mehr Performance gewonnen werden kann, dann macht es Sinn über Caching nachzudenken.
Schon direkt am Anfang ohne Probleme alles zu cachen ist selten sinnvoll und meistens eine Verschwendung von Resourcen(RAM).

Caches machen wirklich erst Sinn wenn man häufig Daten laden müsste und dies zu lange dauern würde, weil z.B. mehrere Millionen Einträge in der DB stehen und du dann schon einige Sek. brauchst um die Daten zu laden.
Ansonsten lass die DB ruhig ihre Arbeit machen, diese kann bei richtiger Optimierung auch ordentliche Performance liefern.

So hatten wir vor einigen Monaten unseren DB Server durch Splitten der Transaktionslog und auch der DB Dateien noch ordentlich Performance entlocken können.
Ist noch ein 2012 R2 SQL Server, die DB selbst lief schon auf einem 2008 R2 DB Server und hatte entsprechend auch nur ein Transaktionslog + eine Datendatei.
Durch das Splitten kann die DB nochmal ordentlich Schreib-/Leseperformance bekommen.
Hier muss nur das Storage, auf dem dann die Dateien liegen, mitspielen.

T-Virus

Ich habe zuerst an das repository pattern gedacht aber nachdem ich diese beiden Blogs gelesen habe bin ich mir da nicht mehr so sicher da einer der Gründe ist das man nur mehr abstracte Layer hat die wohl nicht benötigt werden.

Und was machst Du, wenn Du drei andere Blogs findest, die das Gegenteil behaupten?
Daher halte ich solche Blogbeiträge für nichts sagend; einige auch unseriös.

Es ist die Aufgabe eines Software Designs zu entscheiden, ob ein Pattern sinn macht - oder nicht.
Ich selbst hab nur wenige Fälle gehabt, bei denen wir uns bewusst gegen einen Repository Pattern entschieden haben.

Zu einem Pattern gehört schließlich nicht nur seine Funktion, sondern auch seine Wartbarkeit - und die ist beim Repository Pattern sehr hoch.
Und mit einem sauberen OOP vermeidet man einige Abstraktionen.

Mein datenbankschmea ist relativ komplex

Das behauptet quasi jeder 😉

und ich dachte schon daran einfach nur den DB-Conntext zu nutzen und alles in einer InMermory Database zu speichern, bin mir aber unsicher dabei.

Was ist eine InMemory Datenbank für Dich?
Eine reine InMemory Datenbank ist nicht dafür da, dass etwas persistent gespeichert wird.