it-swarm.com.de

Entities VS Domain Models VS Modelle anzeigen

Es gibt Hunderte von ähnlichen Fragen zu diesem Thema. Aber ich bin immer noch verwirrt und möchte Experten zu diesem Thema beraten lassen.

Wir entwickeln eine Anwendung unter Verwendung von ASP.NET MVC 4 und EF5, und unsere ist der erste Ansatz von DB.

Wir haben die Datenebene in einem separaten Projekt, das eine Klassenbibliothek ist und alle darin definierten Entitäten enthält. Und dann wird Business Layer mit allen Repositorys und Domänenmodellen definiert (ist der richtige Begriff zu verwenden). Und dann kommt die Präsentationsebene.

Derzeit haben wir keine Ansichtsmodelle definiert, wir verwenden die gleichen Domänenmodelle von BL wie Ansichtsmodelle. Bei diesem Ansatz kann eine Zuordnung ausreichend sein.

ENTITY <=> DOMAIN-MODELL

Aber für mich sieht es nicht nach einem guten Design aus. Ich bevorzuge die Definition von Ansichtsmodellen in meiner Präsentationsschicht und die Verwendung von Domänenmodellen für die Kommunikation zwischen Präsentationsschicht und Geschäftsschicht. Konvertieren Sie bei BL Domänenobjekte in Datenentitäten und kommunizieren Sie mit DAL. Bei diesem Ansatz muss ich das Mapping zweimal verwenden.

Modell anzeigen <=> DOMAIN-MODELL <=> ENTITY

Ist mein Domainmodell wirklich notwendig? Kann ich meine Entität nicht verwenden, um mit der Präsentationsebene zu kommunizieren? Gibt es Auswirkungen, wenn ich in meiner Präsentationsebene auf Entitäten verweise? Wenn es welche Auswirkungen gibt?

43
Naresh

Ich denke, Sie haben nur Probleme damit, zu definieren, was jede Ebene ist und welche Rolle sie in Ihrer Lösung spielt.


Datenebene

Ihre Datenebene ist einfach Ihre Datenbank/SharePoint-Liste/CSV-Datei/Excel-Tabelle ... Sie haben die Idee, dass Ihre Daten einfach dort gespeichert werden und in jedem Format vorliegen können. Denken Sie also daran, dass es sich bei der Datenschicht nur um Daten handelt.

// ----------------------------
//    Data tier
//        - MySQL
//        - MS SQL
//        - SharePoint list
//        - Excel
//        - CSV
//        - NoSQL
// ----------------------------

Datenzugriffsschicht

Diese Ebene abstrahiert Ihre Datenquelle und stellt eine API bereit, in der der Rest Ihrer Anwendung mit der Datenquelle interagieren kann.

Beachten Sie, dass unsere Datenquelle eine MS SQL-Datenbank ist und wir Entity Framework für den Zugriff auf die Daten verwenden. Was Sie versuchen zu abstrahieren, ist die Datenbank und das Entity Framework, und Sie haben einen Data Repository für jede Entity.

Beispiel...

Wir haben eine Customers Tabelle in einer MS SQL Datenbank. Jeder Kunde in der Kundentabelle ist eine Entity und wird in Ihrem C # -Code als solcher dargestellt.

Durch die Verwendung des Repository-Musters können wir die Implementierung des Datenzugriffscodes abstrahieren, sodass in Zukunft, wenn sich unsere Datenquelle ändert, der Rest unserer Anwendung nicht betroffen ist. Als Nächstes benötigen wir ein CustomersRepository in unserem Data Access Layer, das Methoden wie Add, Remove und FindById enthält. So abstrahieren Sie jeden Datenzugriffscode. Das folgende Beispiel zeigt, wie Sie dies erreichen würden.

public interface IEntity
{
    int Id { get; set; }
}

public class Customer : IEntity
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public DateTime RegistrationDate { get; set; }
}

public interface IRepository<TEntity> where TEntity : class, IEntity
{
    TEntity FindById(int id);

    void Add(TEntity entity);

    void Remove(TEntity entity);
}

public class CustomerRepository : IRepository<Customer>
{
    public Customer FindById(int id)
    {
        // find the customer using their id
        return null;
    }

    public void Add(Customer customer)
    {
        // add the specified customer to the db
    }

    public void Remove(Customer customer)
    {
        // remove the specified customer from the db
    }
}

Die Datenzugriffsschicht gehört zwischen die Datenschicht und die Geschäftslogik.

// ----------------------------
//    Business logic
// ----------------------------

// ----------------------------
//    Data access layer
//        - Repository 
//        - Domain models / Business models / Entities
// ----------------------------

// ----------------------------
//    Data tier
//        - MySQL
//        - MS SQL
//        - SharePoint list
//        - Excel
//        - CSV
//        - NoSQL
// ----------------------------

Business-Schicht

Die Business-Schicht basiert auf der Datenzugriffsschicht und behandelt keine Bedenken hinsichtlich des Datenzugriffs, sondern ausschließlich die Geschäftslogik. Wenn eine der Geschäftsanforderungen darin bestand, Bestellungen von außerhalb des Vereinigten Königreichs zu verhindern, würde die Geschäftslogikschicht dies handhaben.


Präsentationsstufe

Die Präsentationsebene präsentiert lediglich Ihre Daten. Wenn Sie jedoch nicht genau wissen, welche Daten Sie präsentieren und welche Daten Sie veröffentlichen dürfen, werden Sie sich auf eine Menge Kopfschmerzen einstellen, weshalb dies der Fall ist Für die Verwendung von Ansichtsmodellen ist es wichtig, dass Ansichtsmodelle ein Anliegen der Präsentationsebene sind. Die Präsentationsebene muss nichts über Ihre Domainmodelle wissen, sondern nur über Ansichtsmodelle.

Was sind also Ansichtsmodelle? Es handelt sich lediglich um Datenmodelle, die für jede Ansicht maßgeschneidert sind. Ein Registrierungsformular würde beispielsweise eine RegistrationViewModel enthalten, die diese typischen Eigenschaften offenlegt.

public class RegistrationViewModel
{
    public string Email { get; set; }
    public string Password { get; set; }
    public string ConfirmPassword { get; set; }
}

Auf der Präsentationsebene wird auch die Eingabeüberprüfung ausgeführt. So kann beispielsweise überprüft werden, ob eine eingegebene E-Mail-Adresse das richtige Format aufweist oder ob die eingegebenen Kennwörter der Präsentationsebene und nicht den Geschäftsanforderungen entsprechen. Dies kann mithilfe von Data Annotations erfolgen. .

public class RegistrationViewModel
{
    [Required]
    [DataType(DataType.EmailAddress)]
    public string Email { get; set; }

    [Required]
    [DataType(DataType.Password)]
    [Compare("ConfirmPassword")
    public string Password { get; set; }

    [Required]
    [DataType(DataType.Password)]
    public string ConfirmPassword { get; set; }
}

Die Verwendung von Ansichtsmodellen ist wichtig, da die Geschäftsmodelle zur Geschäftsschicht gehören und Daten enthalten, die privat bleiben sollen. Wenn Sie beispielsweise das Domänenmodell in einer JSON-Antwort verfügbar machen, werden dadurch die gesamten Daten des Benutzers sowie dessen Name und Adresse verfügbar gemacht, da Sie nicht auswählen, was verfügbar gemacht wird und was nicht, sondern was auch immer scheint zu funktionieren.


Ich möchte hier auch darauf hinweisen, dass es einen Unterschied zwischen domain models und entity models gibt. Es gibt bereits eine Antwort, die viel detaillierter ist hier


Querschnittsthemen

Ich werde mich kurz fassen:

  • Ausnahmemanagement
  • Zuordnung von Ansichtsmodellen zu Domänenmodellen.
93
Aydin

Ich bin kein Experte, aber ich werde meine 50 Cent zum Thema teilen.

Modell anzeigen

Ich möchte Ihre Besorgnis über das Ignorieren des Ansichtsmodells teilen.

Mit dem Ansichtsmodell können Sie:

  1. Wählen Sie nur die Daten aus, die Sie aus dem Domänenmodell benötigen
  2. Formatieren Sie die Daten, die Sie benötigen, auf die richtige Weise für die Präsentation (z. B. Formatieren von Preisdezimal (100,00) in Zeichenfolge (100,00 €)).
  3. Sie können DataAnnotation für Ihr Ansichtsmodell verwenden.

Daher halte ich es auch für ein schlechtes Design, aber andere könnten eine andere Meinung haben.

Denken Sie daran, dass die Business-Schicht nichts über das Ansichtsmodell weiß. Sie sollten es daher im Controller zuordnen.

Entities vs Domain-Modell

Ich würde es einfach anfangen und ein POCO als Domänenmodell verwenden, das mit einem ORM oder einem NoRM beibehalten werden kann. Bei den meisten auf der Welt entwickelten Softwareprogrammen kann es Ihrem System nicht sehr schaden, und es ist auch einfach.

Wenn Sie in Zukunft aus irgendeinem Grund mit der Verwendung von Webdiensten beginnen, müssen Sie möglicherweise die Verwendung von DTOs (Data Transfer Objects) für Remoteaufrufe in Betracht ziehen. In diesem Fall können Sie eine weitere Ebene einrichten, die für die Zuordnung Ihres Domain-Modells zum gewünschten DTO verantwortlich ist. Diese Ebene wird nur im Remote-Aufruf (Webdienst) verwendet, wobei das Ansichtsmodell für die Präsentation beibehalten wird.

7
Bruno Costa

Der Hauptvorteil der Einführung zusätzlicher Klassen besteht in der Trennung von Bedenken:

  • Präsentationsschicht: Anzeigeinformationen und Dateneingabe, einschließlich jeglicher Vor- und Nachbearbeitung, um dies zu erreichen, z. Formatierung.
  • Domänen-/Geschäfts-/Anwendungslogik: Hier wird die eigentliche Arbeit erledigt
  • Persistenzschicht: Speichern und Abrufen von Daten

Dies kann mit nur zwei Modellklassen für ViewModels und Domain Entities erreicht werden. Anstatt die Domänenlogik mit separaten Modellklassen zu modellieren, die den persistierten Entitäten ähneln, implementieren Sie sie in Dienstklassen, die die Domänenentitäten verbrauchen. Die Domänenentitäten sollten höchstens eine Logik haben, die sich mit ihren eigenen Eigenschaften befasst (z. B. um die kombinierten Werte von zwei Eigenschaften in einem gültigen Zustand zu halten). Wenn mehr als eine Domänenentität von einem Usecase betroffen ist, modellieren Sie diesen Usecase in einer Serviceklasse. Wenn Sie Logik zum Verwalten der Beziehung zwischen Entitäten direkt in die Entitätsklassen einfügen, ist der Code sehr schnell nicht mehr verwaltbar (vertrauen Sie mir, ich habe es versucht).

Ich empfehle nicht, die persistenten Entitäten als ViewModels zu verwenden, da dies die Anzeigeprobleme (z. B. [DisplayName]) mit Persistenzbedenken (z. B. [ForeignKey]).

1