ASP.NET MVC Zusammenspiel von Datenbank-Entität, Anwendungs-Model, ViewModel

Hallo!

Meine Frage lautet:
Wie kommt man von einer (1) Datenbank-Entität üblicherweise zur einer (2) Anwendungs-Modell das Methoden und Logiken beinhaltet und anschließend wieder zu einem kompakten (3) ViewModel für die View?

Zusammengefasst:
(1)Datenbank-Entität -> (2)Anwendungs-Model (mit Methoden wie z.b. StarteAuto()) -> (3)ViewModel

Im Detail:
(1) Meine "Datenbank-Entität" besteht natürlich au sehr vielen Feldern:

    public class Job
    {
        public int ID { get; set; }
        public int Nr { get; set; }
        public string Name { get; set; }
        public string Beschreibung { get; set; }
        public string Ausführung { get; set; }
        public string Arbeitsschritt { get; set; }
        public string SqlStatement { get; set; }
        public bool IsTäglichAusführen { get; set; }
        public bool IsWöchentlichAusführen { get; set; }
        public bool IsMonatlichAusführen { get; set; }
        public string KontaktEmail { get; set; }
        public bool IsErrorOnResult { get; set; }
        public bool IsErrorOnNoResult { get; set; }
    }

(2) Mein "Anwendungs-Modell" hat eine Methode: "GetAnzahlErgebnisse()":

    public class DqsJob
    {
        public int ID { get; set; }
        public string Name { get; set; }
        public string Beschreibung { get; set; }

        public int GetAnzErgebnisse()
        {
	    // Hier steht irgendeine Logik die auf eine DB zugreif und irgendwas macht etc ...
            return o.Count;
        }
    }

(3) Meine ViewModel braucht nur noch 2 Felder aber das Ergebnis der Anwendungs-Model-Methode: "GetAnzahlErgebnisse()":

    public class DqsJobViewModel
    {
        public string Name { get; set; }
        public int AnzErgebnisse { get; set; }
    }

So hab ich das jetzt einfach mal ausprobiert und würde klappen aber bin mir nicht sicher ob ich jetzt komplett falsch unterwegs bin:

	private DataQualityServiceEntities db = new DataQualityServiceEntities();

        public ActionResult Index()
        {
            // Datenbank-Entität (viele Felder) -> Anwendungs-Model (Hat Logik und Methoden):
            var query = from j in db.Job
                        select new DqsJob
                        {
                            ID = j.ID,
                            Name = j.Name,
                            Beschreibung = j.Beschreibung,
                            Arbeitsschritt = j.Arbeitsschritt
                        };

            // Anwendungs-Model -> ViewModel (Wenig Felder und Ergebnis der Logik):       
            var query2 = from dj in query.ToList()
                         select new DqsJobViewModel
                         {
                            Name = dj.Name,
                            AnzErgebnisse = dj.GetAnzErgebnisse()	<-- Hier wird Logik des Anwedungs-Models ausgeführt und auf das View Model geschrieben.
                         };

            return View(query2.ToList());

Geht das in die richtige Richtung oder bin ich falsch unterwegs?
Sollte ich besser das Ganze mit nur 2 Klassen (Entität -> ViewModel) und einer Helper-Klasse arbeiten?

Danke & lg Gilbert

Naja: so macht man es schon mal nicht.
Normalerweise trennst Du Deine Software nach Schichten: [Artikel] Drei-Schichten-Architektur

Würde heissen Du hast Projekte wie zB

ProjektName.WebApp
ProjektName.DesktopApp
ProjektName.ConsoleApp
ProjektName.Middleware
ProjektName.Middleware.Models
ProjektName.Database
ProjektName.Database.Entities

wobei Du diese jeweils noch - je nach Gesamtanforderung - ebenfalls modularisieren kannst.
Denn die Business-Modelle sind die Middleware.Models, die sich aber von den ViewModels unterscheiden können (und meist werden).
Die ViewModels von WebApps und von DesktopApps unterscheiden sich in aller Regel aber ebenfalls.

Datenbank-Entitäten wiederum spiegel nur genau eine Zeile in einer Tabelle ab.
Je nachdem, ob man zB ORM verwendet oder nicht kann man die ein oder andere Schicht schlanker halten.

PS: Code in Deutsch sieht man selten.
Umlaute sollte man auf alle Fälle vermeiden, auch wenn es _prinzipiell _möglich wäre.
Abkürzungen von Methodennamen ist auch nicht unbedingt perfekter Stil 😉

Hallo!

Vielen Dank für deine Antwort!

3-Tier Architektur setze ich in größeren Anwendungen schon konsequent und gerne ein. Deine Erklärung ist genau das was ich mir erhofft habe und gibt für mich völlig Sinn!

Vielen Dank!
lg mygil

Die Weiterentwicklung der 3-Schichten-Architektur im Web sind die Microservices.