Laden...

.NET core RestApi 2.2 mit EF Core bringt nur ein Teil der Daten an den Client

Erstellt von GrilleGsutav vor 4 Jahren Letzter Beitrag vor 4 Jahren 3.340 Views
Thema geschlossen
G
GrilleGsutav Themenstarter:in
27 Beiträge seit 2017
vor 4 Jahren
.NET core RestApi 2.2 mit EF Core bringt nur ein Teil der Daten an den Client

Hi,

Ich habe das Problem das ich im Controller zwar alle Daten aus der Datenbank geholt werden, aber es kommt nur ein Teil am Endpunkt an.

Controller Methode:


    // GET: api/Domains
    [HttpGet]
    public async Task<ActionResult<IList<Domains>>> GetDomains()
    {
      var test = await _context.Domains.Include(r => r.Records).ToListAsync();
      return Ok(test);
    }

In der Test Variable kommen die Daten richtig an, nach dem return fehlt dann aber ein record.
Models:


  public class Domains
  {
    public int Id { get; set; }
    public string Name { get; set; }
    public string Master { get; set; }
    public int? LastCheck { get; set; }
    public string Type { get; set; }
    public int? NotifiedSerial { get; set; }
    public string Account { get; set; }

    public List<Records> Records { get; set; }

  }
  public class Records
  {
    public long Id { get; set; }
    public int? DomainId { get; set; }
    public string Name { get; set; }
    public string Type { get; set; }
    public string Content { get; set; }
    public int? TTl { get; set; }
    public int? Prio { get; set; }
    public int? ChangeDate { get; set; }
    public Int16 Disabled { get; set; }
    public string Ordername { get; set; }
    public byte Auth { get; set; }

    public Domains Domains { get; set; }
  }

Daten Kontext:


model.Entity<Domains>(d =>
      {
d.HasMany(e => e.Records)
          .WithOne(e => e.Domains)
          .HasForeignKey(e => e.DomainId)
          .HasConstraintName("records_domain_id_ibfk")
          .OnDelete(DeleteBehavior.Cascade);
});

Ich Habe folgende Test Daten in der Datenbank:


new Domains()
          {
            Id = 1,
            Name = "example.com",
            Type = "NATIVE"
          });
new Records()
            {
              Id = 1,
              DomainId = 1,
              Name = "example.com",
              Type = "SOA",
              Content = "ns1.example.com hostmaster.example.com 1 10800 3600 604800 3600",
              TTl = 3600,
              Prio = 0,
              Disabled = 0,
              Auth = 1
            },
            new Records()
            {
              Id = 2,
              DomainId = 1,
              Name = "example.com",
              Type = "NS",
              Content = "ns1.example.com",
              TTl = 3600,
              Prio = 0,
              Disabled = 0,
              Auth = 1
            }

Die Get Methode liefert mir folgenden Json code zurück:


[
    {
        "id": 1,
        "name": "example.com",
        "master": null,
        "lastCheck": null,
        "type": "NATIVE",
        "notifiedSerial": null,
        "account": null,
        "records": [
            {
                "id": 1,
                "domainId": 1,
                "name": "example.com",
                "type": "SOA",
                "content": "ns1.example.com hostmaster.example.com 1 10800 3600 604800 3600",
                "tTl": 3600,
                "prio": 0,
                "changeDate": null,
                "disabled": 0,
                "ordername": null,
                "auth": 1

Weiß vielleicht jemand wo der Fehler liegt?

16.806 Beiträge seit 2008
vor 4 Jahren

I.d.R. ist es keine gute Idee, dass Du Datenbank-Enitäten direkt aus der API raus gibst.
Damit schaffst Du Dir eine enorme Abhängigkeit zwischen API- und Datenbankdesign.

Was mir generell auffällt:

  • Wenn Du Deine Navigation Properties ohne virtual deklarierst, brauchst Du eigentlich kein Include
    - Klassen sollten im Singular benannt werden

Meine Vermutung: es ist ein Serialisierungsproblem.
Ist oft und typisch, wenn man Datenbank-Entitäten mit Relationen 1:1 aus der API raus gibt.

Hier sollte man auf das Reference Loop Handling achten. Sollte ignoriert werden.

services.AddMvc()
   .AddJsonOptions(options => {
      options.SerializerSettings.ReferenceLoopHandling = ReferenceLoopHandling.Ignore;
});

Aber mein Rat aus reichlich Erfahrung: lass das mit den Entitäten aus der API raus zu geben und mach es ordentlich 😉

G
GrilleGsutav Themenstarter:in
27 Beiträge seit 2017
vor 4 Jahren

lol das soll unsauber sein???

Die Api ist nur für direkte Kommunikation mit Angular Frontend.

Was du unter sauber verstehst möchte ich jetzt doch mal wissen?
Natürlich mit EntityFrameworkCore.

Gruß

Grille

16.806 Beiträge seit 2008
vor 4 Jahren

lol das soll unsauber sein???

"lol" 🤔
Ja ist es - sehr sogar. Das zeigt Dir quasi auch jedes Buch über moderne und saubere Architekturen auf Basis von ASP.NET Core oder ähnlichen Frameworks.
Ein kostenloses Buch bietet dazu auch Microsoft: https://dotnet.microsoft.com/learn/aspnet/architecture
Hier werden auch die entsprechenden Software Architekturpattern gezeigt - und auch erklärt, wieso Dein Ansatz nicht zu den empfohlenen Wegen gehört.
Ob EF Core oder nicht spielt bei einer API Architektur keine Rolle.

Es ist prinzipiell sehr unsauber, dass Du Entitäten 1:1 über die API raus gibst.
Jegliche Änderungen Deiner Datenbank wirken sich so 1:1 auch auf das API Modell aus - ob Du willst oder nicht.

Abstrakes Beispiel:
Hättest Du hier als Beispiel einen Benutzer mit seinem Passwort, würdest Du so 1:1 auch das Passwort raus geben. Willst Du das wirklich?
Bei Dir sind es eben sekundäre Informationen über die Domains.

Deine Datenmodelle sind für APIs auch eher ungewöhnlich:

  • Zeitstempel als Int statt als ISO8601
  • Zustände via Int16

Anderes Beispiel: würdest Du die Entitäten nicht nur zurückgeben sondern zB auch akzeptieren, dann hätte der Aufrufende die Möglichkeit Dinge zu setzen, die er gar nicht setzen darf:
zB hat ein Id-Feld beim Erstellen nichts in der API zu suchen: der Service ist i.d.R. für das Erstellen der Id verantwortlich und nicht der aufrufende.
Ergo hat dieses Feld im POST/PUT auch nichts verloren (wie auch andere Felder).

Du kannst das alles Beibehalten, wenn das Dein Datenbankschema auch so erfordert: Du API Modelle kannst Du das aber alles sauber raus geben (Enum statt Int16 (oder eben bool, je nachdem)) und DateTimeOffset für Zeitstempel.

Im Frontend Bereich verwendet man ViewModels: diese haben nur die Informationen, die auch tatsächlich benötigt werden.
Ebenso ist die View nicht mehr vom Modell der Datenbank abhängig.

Deine Json API hier ist aus der Sicht der Architektur nichts anderes als eine View.
Es bieten sich hier eben API Modelle an - das ist völlig üblich und auch der empfohlene Weg.
Letztes Jahr habe ich mehrere Talks zu dem Thema gehalten und auch über die Entwicklungsstufen von APIs: https://github.com/BenjaminAbt/2018-Talks-ModernApiDevelopment
Hier siehst Du einfache Json APIs, Json APIs mit SDK und auch neuere Ansätze wie GraphQL, OData und Co.

Datenbankmodelle gibt man aber niemals raus.
Basics dazu u.a. auch hier: [Artikel] Drei-Schichten-Architektur

Du kannst das alles auch so beibehalten; das ist dann Kategorie pragmatisch statt "sauber" 🙂

G
GrilleGsutav Themenstarter:in
27 Beiträge seit 2017
vor 4 Jahren

Letzten Endes kommt die Datenbank Struktur nicht von mir, sondern wird von PowerDNS so vorgegeben und damit PowerDns sauber mit der Datenbank arbeiten kann, habe ich diese Struktur 1 zu 1 nach zu bilden. Viewmodels sind mir ja bekannt. Es ging erstmal darum alles so einfach wie möglich ans laufen zu kriegen. Ich mache es ja nicht anders wie Microsoft in seinen diversen Beispielen auch.
Ob MVC oder MVVM sind beides ja nicht verkehrte Ansätze.

Ich finde es ist nicht leicht mit EF Core auf eine schon vorhandene Datenbank aufzusetzen.
Zum Beispiel die Teamspeak 3 Datenbank, die ist einfach extrem miserabel umgesetzt. Dort sind z.B. Alle Beziehungen zwischen den Tabellen in der Application Logik vom TS3 server. Viele Tabellen haben nicht mal eine Primary Key. Das lässt sich mit Ef Core gar nicht umsetzten weil der so dirty gar nicht zu lässt.

Wäre das jetzt meine eigene Datenbank Struktur sehe das ganz anders aus.

Gruß
Grille

T
2.219 Beiträge seit 2008
vor 4 Jahren

@Abt
Ich würde es nicht mal als pragmatischen Ansatz sehen, da auch pragmatische Lösungen sauber sein sollten 😃

Anbei haben wir bei uns vor einigen Monaten auch eine WebAPI mit Json als Format umgesetzt.
Hier habe ich für jede Api und deren Aufrufe eigene Request/Response Modelle.
Auch wenn der Response im Kern dann durch eine Basis Klasse identisch ist, Status Property mit entsprechenden Informationen, gibt es für jeden Aufruf eigene Klasse für Request und Response.

Wie Abt schon sagt, sichert man damit auch gleich die API gegen ungültige Werte ab.
Dazu gehören neben den PK Werten ggf. auch Zuweisungen von Daten an Benutzer oder gar ganze Mandanten.
Wenn du hier leichtsinnig deine API umsetzt, kann man diese ohne Probleme nutzen um deine DB entweder mit Müll zufluten oder far einfach alle Daten abzugrassen.
Im letzten Fall dürftest du bei kritischen Benutzerdaten massive Datenschutz Probleme bekommen.

Ebenfalls gibst du mit den Datenstrukturen auch deine Architektur zum Stück auch preist in dem du das ganze Datenmodell raus gibst.
Damit machst du es der Konkurrenz auch einfach deine Strukturen nachzubauen, solltest du mal das 1 Million Euro Projekt bauen 😉

Ich empfehle dir gerade bei den öffetlichen APIs sehr sorgfältig zu sein, da gerade diese auch eine Angriffsfläche darstellen.
Gerade dies wird häufig auf die leichte Schulter genommen, was dann gerne mal zum ablauf von Daten führt.
Auch große Konzerne aus Übersee machen hier gerne mal katastrophale Fehler und machen es damit leicht Daten im großen Umfang abzusaugen, ich erinnere nur ungern an Facebook und Cambridge Analystics.

Nachtrag:
@GrilleGsutav
Ob es deine Datenbankstruktur oder eine fremde ist, spielt hier keine Rolle.
Du gibst 1:1 die Datenbank Entität raus, das sollst du aber nicht tun.
Hier musst du deine Daten auf ein Modell nur für die API mappen und dann die Instanz des Api Modells liefern.
Da hier vermutlich nur ein Tel der Daten aus der Entität benötigt werden, kannst du damit bei vielen oder großen Abfragen auch einiges an Daten sparen, was vorallem den Traffic für den Client/Server sowie die Rechenleistung zum serailisieren der Daten auf Serverseite entlastet.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.806 Beiträge seit 2008
vor 4 Jahren

@Abt
Ich würde es nicht mal als pragmatischen Ansatz sehen, da auch pragmatische Lösungen sauber sein sollten 😃

Wenn das ein rein lesendes Thema ist, dann ist das ein pragmatischer Ansatz.
Ich bleib dabei 😃

Letzten Endes kommt die Datenbank Struktur nicht von mir, sondern wird von PowerDNS so vorgegeben

Umso mehr ein Grund ordentliche ViewModels zu verwenden.
Wenn PowerDNS die Struktur ändern sollte, dann bist Du gleichzeitig gezwungen Deine UI zu ändern. Willst Du das wirklich?

Zudem arbeitet JavaScript (respektive Angular) bei Datumsformaten mit Date().
Du müsstest also manuell in der UI den Datentyp umwandeln.
Wozu? Das ist Aufgabe der API dem Frontend die korrekten Formate zu geben und Defizite in der Datenbankstruktur nicht auch noch durchzureichen.
Du kannst also problemlos im API ViewModel mit DateTimeOffset arbeiten und in der Datenbank aufgrund der Abhängigkeit zu PowerDNS eben mit Linux Int-basierten Zeitstempeln.

Ich finde es ist nicht leicht mit EF Core auf eine schon vorhandene Datenbank aufzusetzen.

Letzten Endes ist das auch alles nur ein Code First Vorgehen.

Seit EF Core 2.1 werden auch Tabellen ohne Primary Key unterstützt. Nennt sich Query Type Support.
Ist leider ein gar nicht so seltener Fall 😃

G
GrilleGsutav Themenstarter:in
27 Beiträge seit 2017
vor 4 Jahren

Wie gesagt es ist ja nur die erste Ausbaustufe, so wollte ich das ja nicht lassen.
Das ohne Primary Key mittlerweile auch geht wusste ich nicht.

Ich für meinen teil finde es besser mit sauberen Beziehungen in der Datenbank zu arbeiten.
Vernünftige Normalisierung.

Wo es sinn macht nutze ich auch No-SQL Datenbanken(MongoDb)

Gruß

Grille

G
GrilleGsutav Themenstarter:in
27 Beiträge seit 2017
vor 4 Jahren

services.AddMvc()
   .AddJsonOptions(options => {
      options.SerializerSettings.ReferenceLoopHandling = ReferenceLoopHandling.Ignore;
});

Das hat geholfen danke

Gruß

Grille

D
161 Beiträge seit 2017
vor 4 Jahren

@Abt hab dann doch dazu auch eine Frage.

  • Wenn Du Deine Navigation Properties ohne virtual deklarierst, brauchst Du eigentlich kein Include

Hat er doch? Oder übersehe ich die gerade lediglich? Habe meine auch ohne virtual deklariert und brauche dennoch das Include().

I.d.R. ist es keine gute Idee, dass Du Datenbank-Enitäten direkt aus der API raus gibst.

Wie denn sonst, wenn man im ApiController mit dem DBContext arbeitet?

Du nimmst bei deinem Talk einen dritt Anbieter. Den du Befehle mitteilst.


        private readonly IMediator _mediator;

        public AuthorsController(IMediator mediator)
        {
            _mediator = mediator;
        }

        [HttpGet]
        public async Task<ActionResult<IEnumerable<AuthorApiViewModel>>> Get()
        {
            IList<Author> result = await _mediator.Send(new GetAllAuthorsQuery());

            IEnumerable<AuthorApiViewModel> viewModels = result.Select(AuthorApiMapper.MapToApiModel);
            return Ok(viewModels);
        }

Aber, wenn man keinen dritt Anbieter nutzt, kann man doch nichts anderes machen, als die Entität zurückzugeben?

Grüße

T
2.219 Beiträge seit 2008
vor 4 Jahren

Im besten Fall arbeitest du gar nicht mit dem DbContext im Api Controller geschwiege den auf dieser Ebene.
Wenn du es sauber weg kapselst, wäre der DbContext nur im Data Layer, wo er auch hingehört.
Wenn du Daten aus der DB brauchst, dann musst du den Weg über die Schichten gehen.
Den DbContext schon bis in die UI Schicht zu ziehen ist schon eine Verletzung der Schichten.

Und wie oben schon geschrieben steht, musst du ein eigenes Datenmodell für deine Api umsetzen, was dann die Daten liefert.
Ebend ein View Model für die API.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

2.298 Beiträge seit 2010
vor 4 Jahren

Du kannst aber eine öffentliche Entität für die Rückgabe an den Aufrufer der API erstellen und intern mit einer DB-basierten Entität arbeiten. Damit ist nach außen nicht sichtbar, wie die interne Struktur ist. Du hast dann quasi Übergabetypen und die eigentlichen innerhalb der API und Datenbank verwendeten Typen.

Diese haben natürlich eine Schnittmenge an Daten. Aber die Trennung von API Aufrufer und Datenbank ist damit deutlich sauberer. - Ändert sich nun die DB Struktur und bestimmte Daten sind plötzlich in anderen Tabellen änderst du API intern das Füllen der Übergabeobjekte ohne diese auch nur ein Stück weit anzupassen. Damit sind auf Aufruferseite erst einmal keine Änderungen notwendig.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

D
161 Beiträge seit 2017
vor 4 Jahren

Also für die Entitäten neue Klassen erstellen mit benötigten Werten.

16.806 Beiträge seit 2008
vor 4 Jahren

Es geht darum, dass Du Modelle machst, die Du aus der API rausgeben kannst.
Deine Entitäten wissen nicht, ob sie von einer Webanwendung oder einer Desktopanwendung verwendet werden.

Im Prinzip hast Du pro Anwendungstechnologie (WinForms, ASP, WPF...) eigene UI Modelle; teilst aber Business- und Datenbankmodelle.
Bei ASP heisst das üblicherweise halt dann ViewModel (für HTML) oder eben ApiModel für Json-Rückgaben; wie es eben auch ViewModels in WPF sind.
Das ist die Grundidee dahinter.

Aber, wenn man keinen dritt Anbieter nutzt, kann man doch nichts anderes machen, als die Entität zurückzugeben?

Ich vermute, dass Du mit Dittanbieter MediatR meinst.

MediatR ist nur eine verdammt gute Bibliothek, mit dem sich das Trennen von Logik und Präsentation extrem einfach und flexibel umsetzen lässt (im Prinzip CQRS Pattern).
Daher ist das prinzipiell auch vollständiger Standard in all meinen Projekten und verwende ich auch ausgiebig in Beispielanwendungen.

Riesen Vorteil ist, dass sich über MediatR auch super Projectionsmodelle erzeugen lassen: sprich ich bei einer API Anfrage nur die Daten lade, die ich auch wirklich brauche - und vom eigentlichen Logik- oder Datenbankaufbau in der Anwendung nichts wissen muss.

MediatR ist auch der Grundpfeiler der neuen Forenbasis von mycsharp.de

G
GrilleGsutav Themenstarter:in
27 Beiträge seit 2017
vor 4 Jahren

Also in der heutigen zeit, wo es durchaus sinn macht auf Themen wie z.B. Electron und Angular zu setzen, da hast du für all deien Anwendungen ein Backend und Frontend.
Also ändert sich auch deine Modelstruktur nicht, ganz gleich ob Desktop oder Webanwendung.
Außerdem muss ich, wenn ich in den Models neue werte hinzufüge und diese auf am Frontend haben möchte, auch die Viewmodels anpassen.

Ich finde es nicht gut ohne ende Dritanbieter Tools zu setzen.
Solange ich .net core einsetze muss ich nciht ständig drauf achten, das auch alle Drittanbieter Tools, mit der einem Update von .net noch kompatible sind.

T
2.219 Beiträge seit 2008
vor 4 Jahren

@GrilleGsutav
Was?
Die Aussage ist totaler Unsinn.

.NET Anwendungen sind so kompatibel, dass ich selbst eine .NET 2.0 Anwendung ohne Probleme auf .NET 4.8 laufen lassen kann und wenn keine krassen Abhängigkeiten hängen sogar auf .NET Core.
Und .NET 2.0 ist schon über 10 Jahre alt.

Du hast eher einen Bruch beim updaten von NuGet Paketen wegen API Änderungen in den jeweiligen Paketen was aber absolut normale ist wenn sich die API ändert.
Als Entwickler ist es dann deine Aufgabe solche Änderungen zu verstehen und deinen Code anzupassen.

Deine Aussage zu den modellsturkturen ist ebenfalls Käse.
Bei Software sind Änderungen an Datenmodell gängige Praxis, da sich viele Modelle immer weiter entwickeln oder irgendwann mal auch entschlackt werden.
Schau dir mal das Thema der API Versionierung an, dann zerfliegt deine These ganz schnell.

Ohne Ende auf Drittanbieter Tools setzen ist auch nicht ziel führend.
Du solltest alles, was es schon in fertiger Format gibt, auch durch Libs/Tools abdecken lassen die ihren Zweck bereits optimal abdecken.
Sonst gehst du wieder dem NIH-Syndrom auf den Leim.

Ob du .NET Core, .NET oder Java oder sonst eine Laufzeit verwendet, spielt i.d.R. nur selten eine Rolle.
Nur wenn die Laufzeiten eben einen krasse Breaking Change haben, kann es zu deinem Problem kommen.
Im .NET Bereich ist dies nur von .NET Framework zu .NET Core der fall gewesen, weshalb sich der .NET Standard auch etabliert hat um dieses Problem zu lösen um die Brücke zwischen .NET Framework und .NET Code herzustellen.

Ob du Electron, Angular oder reines JS verwendest im Frontend verwendest ist hier übrigens unerheblich.
Hat mit der API 0 zu tun, da jedes Tools deine API nutzen kann solange es HTTP verwendet.
Und bezogen auf das aktuelle Thema geht es hier nur um die API und den Code den du produziert hast.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.806 Beiträge seit 2008
vor 4 Jahren

T-Virus bringts ziemlich auf den Punkt:
Wenn Du unter dem Not-invented-here-Syndrom leidest, dann ist das ein generelles Problem, das ohnehin nicht durch Software zu lösen ist.
Dann weiß ich nicht, was Du für eine Antwort erwartest.

G
GrilleGsutav Themenstarter:in
27 Beiträge seit 2017
vor 4 Jahren

Bei Drittanbieter Tools weiß ich doch nie wie lange die noch geflegt werden.
z.B. ist .net Core 3.0 draußen und in dem zuge hat sich in EntityFrameworkCore auch viel getan, was
dann wiederum den Datenbank Provieder von Oracle für MariaDb brocken macht.
Die Ewige verschieberei von .net core Releases macht es den Enticklern von Drittanbieter Tools nicht leicht dann auch zum release Tag Fertig zu sein.

Ich würde gerne einiege Features aus 3.0 nutzen, kann dies aber nicht weil dann meine Datenbank nicht mehr abfragen kann.

Also gehe ich davon aus, dass um so mehr Tools von Dritten ich benutze, das ich noch mehr solche Probleme kriege.

T
2.219 Beiträge seit 2008
vor 4 Jahren

Liegt aber an .NET Core, was so oder so im nächsten Jahr zu .NET 5.0 wird.
Da .NET Core eine Neuentwicklung von .NET ist war eigentlich jedem klar, dass hier noch im laufe der Zeit viele Breaking Changes kommen.
Wenn du eine lanfristig stabile .NET Version brauchst, dann solltest du auch eher mit .NET Framework arbeiten.

Ansonsten ist .NET Core 3.0 soweit auch fertig, Microsoft hat hier die wichtigsten APIs übernommen und mehr kommt da auch nicht.

Anbei hat die .NET Core Version recht wenig mit den Dritt Anbeiter Tools und den Probleme zu tun.
Wenn die Libs nicht auf .NET Core 3.0 gehen können, kannst du dies eben auch nicht.
Auch hier ist es deine Aufgabe solche Probleme zu analysieren und darauf zu reagieren.
In dem Fall eben, in dem du wartest bis die entsprechende Lib auch .NET Core 3.0 supportet.

Wenn du aber selbst einfach überhastet ein Update auf .NET Core 3.0 macht ohne die Probleme die damit einher gehen zu evaluieren, hast du einen fatalen Fehler gemacht.
Dafür können die Drittanbieter nichts und es ist auch nicht deren Problem sondern allein deins!
Ob du dann ein Drittanbieter Tool/Lib oder 1.000 verwendest ist dann total egal, da du ohne Prüfung einfach was machst und es knallt.

Du als Entwickler bist dafür verantwortlich, dass du solche Probleme erkennst und im eigentlichen Entwicklungsprozess behebst.
Und wenn die Lösung eben warten heißt, dann muss man eben warten.
Einen Grund direkt auf .NET Core 3.0 zu gehen bei einem lauffähigen Projekt gibt es nicht.
Support für die letzte LTS Version gibt es noch ca. 2 Jahre.

Nachtrag:
Ebenfalls ist EF Core nicht irgendein Drittanbieter Tool.
Dies gehört wire .NET Core zu Microsoft selbst.
Wenn hier aber der MariaDB Provider nicht rechtzeitig nachgezogen wurde, liegt dies am Maintainer des Providers nicht aber an EF Core oder .NET Core.
Genauso wie alle anderen Provider die Microsoft nicht pflegt liegt die Verantwortung bei den Maintainern der jeweiligen Provider.

Nachtrag 2:
Laut NuGet und der Liste von Microsoft zu den bekannten Providern gibt es für den einzigen MariDB Provider bereits RC Versionen, die letzte ist erst 5 Tage alt.
Damit hättest du auch arbeiten können, wenn du den auch mit RC arbeiten kannst.

EF Core Provider
NuGet Paket

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

G
GrilleGsutav Themenstarter:in
27 Beiträge seit 2017
vor 4 Jahren

Ihr seid echt geil wie ihr einem das Wort im Mund rum dreht.
Habe doch nie gesagt das efcore ein Drittanbieter Tool ist.

Pomelo.EntityFrameworkCore.MySql kann ich nicht nutzen weil die von mir benötigte dinge nicht unterstützen.

Ihr redet hier alle so schlau daher, kenn aber nicht im Ansatz mein Projekt.
Oder wisst warum ich manche pakete nutze und andere aben nicht.

T
2.219 Beiträge seit 2008
vor 4 Jahren

Ist auch nicht unsere Aufgabe deine Pakete zu kennen.
Wir können dir nur Ratschläge geben.
Aber wenn du diese nicht willst, kann dir hier keiner helfen.

Aber auch hier gilt, wenn der Provider durch ein Update auf .NET Core 3.0, was du ja veranlasst hast, kaputt geht, ist es deine Aufgabe die Probleme zu lösen.
Notfalls eben durch ein Revert auf den alten Stand mit einer älteren .NET Core Version bis der Support für .NET Core 3.0 da ist.

Wir drehen dir hier auch nicht das Wort im Mund herum.
Wir wollen dir lediglich erklären, wie du sauberen Code schreibst und welche Probleme deine aktuellen Ansätze offensichtlich verursachen.
Aber auch hier gilt, keiner Zwingt dich die Ratschläge zu beherzigen.
Nur darfst du dich dann nicht über die hier angesprochenen Probleme beschweren!

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

Hinweis von Abt vor 4 Jahren

Ich mach hier mal dicht...

Thema geschlossen