Bit pro Bit, ich bin unerschöpflich und werde mit ASP.NET MVC4 besser vertraut. Allerdings bin ich mir in diesem sehr wichtigen Punkt immer noch nicht klar darüber. Sagen wir, ich habe ein Modell:
%Vor%Ich benutze dieses Modell mit Entity Framework Code ersten Ansatz und ich habe den folgenden DB Kontext:
%Vor%Was ich nicht verstehe, ist: Was ist der Model Layer und was ist der Data Access Layer? Für mich ist die WorkPaper-Klasse ein Teil der DAL, seit ich sie entworfen habe und meine Eigenschaftennamen und -typen (Navigationseigenschaften usw.) so gewählt habe, dass sie dem EF-Muster entsprechen. Aber das Problem ist, dass wenn ich recht habe, ich wirklich nicht sehe, wo ich die Geschäftslogik setzen sollte.
In diesem speziellen Fall, wenn ich eine Regel hinzufügen möchte, die besagt, dass ein Workpaper nicht gesendet werden kann, wenn sie nicht verifiziert wurde, und eine andere Regel, die besagt, dass sie nicht eingereicht werden kann, wenn sie vor mehr als 2 Wochen hinzugefügt wurde (seltsame Regeln, aber das ist nur ein Beispiel). Wo sollte ich sie hinzufügen? Muss ich eine andere Klasse erstellen, aber wo soll ich sie dann hinstellen und was soll sie enthalten? Wird es mit der Klasse, die ich bereits habe, nicht sehr überflüssig sein? Aber andererseits, da diese Klasse "datenbankorientiert" ist, wäre es nicht chaotisch, dort Geschäftsregeln hinzuzufügen?
Mein Punkt ist wirklich zu verstehen, wo ich meine Geschäftslogik setzen und den Unterschied zwischen der DAL und dem Modell verstehen muss. Ich habe Schwierigkeiten, die DAL und die Model Layer zu identifizieren, da sie mir sehr ähnlich sind. Ich würde gerne die Dinge richtig machen.
(Grundsätzlich weiß ich nicht, wo ich "mein Programm" mit MVC programmieren soll! Ich fühle mich nicht wohl, sobald ich die Funktionalität programmieren möchte, die mich wirklich interessiert. Ich habe das Gefühl, dass ich es nicht tue die Dinge richtig)
Es gibt keinen einzigen "richtigen" Weg, dies zu tun. Es gibt wahrscheinlich eine Anzahl von "falschen" Wegen, aber wie bei den meisten Dingen ist viel davon "es kommt darauf an".
Sie werden eine Menge Meinungen dazu finden. Und vieles davon hängt davon ab, wie Sie sich ihm nähern. Zum Beispiel schlägt @Tarzan vor, Ihr Modell sowohl für Geschäftslogik- als auch Datenschicht-Entitäten zu verwenden. Andere schlagen vor, separate Entity-Objekte, Business-Objekte und Modellobjekte zu erstellen.
Wenn Sie eine relativ einfache Anwendung vom Typ CRUD erstellen, können Sie wahrscheinlich tun, wie @Tarzan es vorschlägt und wenige Probleme haben. Bei komplexeren Anwendungen treten jedoch Probleme auf. Was passiert zum Beispiel, wenn sich Ihre Geschäftslogik von Ihrer Datenlogik unterscheidet? Wenn Sie sie zu einem einzigen Satz von Entitäten kombinieren, müssen Sie die Logik überall gleich machen oder viel Zeit für die Nachrüstung aufwenden.
Der flexibelste Ansatz besteht darin, Ihre Präsentations-, Geschäfts- und Datenebenen vollständig voneinander zu trennen. Auf diese Weise müssen die Anforderungen von (z. B.) der Benutzeroberfläche nicht mit den anderen Ebenen übereinstimmen. (Hier ein einfaches Beispiel: Stellen Sie sich vor, dass ein bestimmtes Feld für einige Arten von Objekten null sein darf, für andere jedoch nicht. Ihre Datenschicht würde nur wissen, dass das Feld Nullwerte enthalten kann, während Ihre Geschäftsschicht bestimmte Objekte kennt 't sein null).
Allerdings kann dieser Ansatz viel Overhead haben und erfordert, was in jeder Ebene wie doppelter Code erscheint ... was viel zusätzlichen Aufwand bedeutet, was sich oft für kleine oder einfache Anwendungen nicht lohnt.
>Eine wichtige Sache zu erinnern ist, dass MVC ein Präsentationsmuster ist. Das heißt, es betrifft NUR die Benutzeroberfläche. Das "Modell" wird typischerweise als "Ansichtsmodell" betrachtet, welches das Modell ist, das die Ansicht verwendet. Dieses Modell ist an die Sichtenanforderungen angepasst. Zum Beispiel durch Verwendung von Datenattributen, die Sie nicht in ein Datenmodell einfügen würden.
Wenn Sie MVC als rein präsentativ betrachten, ist MVC egal, welche Art von Datenzugriff Sie verwenden und welche Art von Business-Schicht Sie verwenden. Dies kann eine Serviceschicht oder ein Repository oder eine Business-Objektbibliothek (z. B. CSLA) sein.
Ein gebräuchliches Muster in MVC-Anwendungen ist die Verwendung eines Service-Layers eines bestimmten Typs oder eines Repositorys, wenn Sie nur CRUD-Vorgänge ausführen. Es gibt normalerweise eine Art von Mapping-System zwischen den einzelnen Ebenen, die Technologien wie AutoMapper oder benutzerdefinierte Build-Mapping-Klassen verwenden.
Der Punkt hier ist einfach das. MVC beschäftigt sich nicht mit Geschäft und Daten, also machen Sie sich nicht alle Gedanken darüber, wie diese in eine MVC-Anwendung passen. Sie tun es nicht oder zumindest nicht anders als mit sehr einfachen Schnittstellen.
Ihre Anwendung ist eine Sammlung von Objekten, die als Architektur betrachtet werden können. Diese Architektur besteht aus verschiedenen Schichten. MVC, Service, Daten, etc .. MVC kann die primäre Benutzeroberfläche sein, aber das bedeutet nicht alles andere ist auch MVC.
Sie können die NicodemeContext-Klasse in die DAL- und die WorkPaper-Klasse in der Modellschicht einfügen.
Eine nützliche Technik ist die Verwendung von Teilklassen im Modell. Bewahren Sie in einer Teilklasse alles auf, was von einem Codegenerator geschrieben werden könnte und alles handgeschrieben in der anderen Teilklasse. Wenn Sie z. B. ein Werkzeug zum Generieren einer partiellen WorkPaper-Klasse verwenden, enthält es normalerweise alle Eigenschaften und Verknüpfungen. In der handschriftlichen Teilklasse können Sie Ihre Geschäftslogik platzieren. Wenn sich in Ihrer Domain etwas ändert, können Sie den Klassengenerator immer wieder ausführen, ohne Angst davor zu haben, Ihre Geschäftslogik zu verlieren. Ich weiß, dass du gesagt hast, dass du zuerst Code verwendest, aber dennoch können Teilklassen nützlich sein.
Modelle sind, wo Sie Geschäftslogik setzen und mit der Datenzugriffsebene kommunizieren, die & amp; ruft Daten ab. Ihre Ansichten dienen zur Darstellung der Benutzeroberfläche. Die Controller dienen zum Weiterleiten von Informationen zwischen Ansichten und Modellen. Es dauert eine Weile, um MVC zu fühlen, aber Sie stellen die richtigen Fragen und sind auf dem richtigen Weg.
Hoffe, das hilft. Prost.
Tags und Links c# entity-framework asp.net-mvc-4 data-access-layer