Business-Logik in Entity-Framework integriert

Ich habe einige der Artikel auf BL gelesen, aber die Methodik scheint mir intuitiv entgegenzuwirken. Es scheint normale OOP-Prinzipien aufzubrechen. Hier ein sehr vereinfachtes Beispiel: Eine Client-Tabelle enthält das Geburtsdatum und das Geschlecht jedes Kunden. Eine Lebenserwartungstabelle enthält die Client-ID, das Alter und die Wahrscheinlichkeit des Überlebens in diesem Alter.Business-Logik in Entity-Framework integriert

Müssten nicht grundlegende OOP-Prinzipien Methoden in die Entität integrieren? Z.B. die calculateSPTable() -Methode in der Client-Klasse.

Die heutigen Methoden scheinen jedoch darauf hinzudeuten, dass solche Operationen in einer separaten Schicht und einer separaten Klasse erfolgen müssen. Methoden, die für Entitäten verwendet werden, sollten nicht in Entitätsrahmeneinheiten enthalten sein. Dies scheint kontraproduktiv zu sein. Ich möchte wirklich Methoden in EF-Entitäten einfügen. Wird das zu Problemen führen? Was fehlt mir hier?

Quelle

2016-04-26 jlear

Entity Framework ordnet Ihr Entities-Objekt (z. B. Eigenschaften, Methoden, Enum usw.) durch Reflexion zu. Denken Sie jetzt darüber nach, eine Entität hat 10 Eigenschaften und 10 Methoden vergleichen sie mit einer anderen Entität mit 10 Eigenschaften, die eine schnellere Zuordnung haben werden? –

Ich denke, ich verstehe Eigenschaft Zuordnung, aber ich bin mir nicht sicher, wie Methoden zugeordnet werden. – jlear

Nach ein paar Recherchen benutze ich nun einige Muster, die meiner Meinung nach gut für die Wartung von Schweinswalen sind und die Anwendung verstehen. Angenommen, Sie möchten ein Konto erstellen. In der Steuerung hätte ich ein AddAccountViewModel, das einem Benutzer nur die minimalen Eigenschaften verfügbar macht. Keine Sorge, dass er etwas Schlechtes in ein unerwartetes Eigentum injiziert. Jetzt würde ich mit Hilfe der Abhängigkeitsinjektion eine Fassade aufrufen. Lassen Sie uns _accountsFacade.RegisterAccount sagen und ich würde das Ansichtsmodell als Parameter übergeben. Innerhalb dieser Methode in der Fassade würde ich das Mapping vom View-Modell zum Model machen und diese Facade wäre dafür verantwortlich, alles zu tun, was getan werden musste, damit das Konto erstellt werden konnte. Hier ist meiner Meinung nach die ganze Geschäftslogik. In dieser Facade benutze ich wieder eine Abhängigkeitsinjektion, verwende eine Arbeitseinheit und füge Entitäten dem Kontext hinzu und bearbeite sie. _unitOfWork.AccountRepository.Add (Konto) Sie sehen? Controller "routen" nur die Anwendung, Fassaden behandeln das Geschäft, die Arbeitseinheit den Kontext, das Repository kommuniziert nur mit der Datenbank ... Und das Modell gibt nur Eigenschaften frei. Dies macht das Mapping schneller, wie gesagt, und es trennt Bedenken. Manchmal kann die Logik des Hinzufügens eines Kontos die Verarbeitung verschiedener Objekte beinhalten, die nicht innerhalb des Account-Objekts verwendet werden sollten. Ich hoffe, Sie können verstehen, was ich erklären möchte, da mein Englisch nicht so gut ist. War es hilfreich?

Quelle

2016-04-26 08:59:32

Es scheint, dass der DBContext die Grenze ist, die Interessen trennt, nicht die Entitäten. DI tritt am DBContext auf. Die Entitäten und die Geschäftslogik sollten sich nicht mit DI ändern. Der Schlüssel zur Antwort scheint zu sein, dass Mapping-Methoden die Dinge verlangsamen, aber ich verstehe nicht, welche Methode Mapping ist, wie es die Dinge verlangsamt. Es scheint, dass Methoden durch Mapping ignoriert werden sollten. – jlear

Business-Logik in Entity-Framework integriert

Antwort

Verwandte Themen