Wie definieren Sie den Unterschied zwischen business-Modell und ein Daten-Modell?
Ich sehen, der Begriff wird Häufig verwendet, als ob es einen konkreten Unterschied zwischen den beiden, bei der Diskussion über MVC für OO-Sprachen. Von dem, was ich von Zusammenhang ist es Geschäftsmodelle, die eine Aktion ausführen zu mutieren der Daten die Modelle. Ist das eine korrekte Art und Weise zu äußern, den Unterschied.
Ich denke, was mich verwirrt ist aber, dass die meisten Beispiele von Modellen mischen beide diese Rollen und auf der Oberfläche fühlt es sich natürlich, das zu tun. Oft werden die Methoden, die Objekte ändern Staaten sind innerhalb dieser Objekte selbst. Ich denke, dass ich Schwierigkeiten haben, kommen mit einem Beispiel, wie das funktioniert in der realen Welt. Es scheint mehr Natürliche Methoden, die ein Objekt ändern, werden innerhalb dieses Objektes. Kann einer erklären, das ein wenig klarer?
- Business Modell-und Daten-Modell nichts zu tun haben mit MVC. Es spielt keine Rolle, was das front-end ist (MVC, Silverlight, ...), es sollte getrennt werden von Ihrem Business Layer und Data Layer.
- Wenn Sie sagen, dass "oft die Methoden, die Objekte ändern Staaten sind innerhalb dieser Objekte selbst" Sie sind (wahrscheinlich) sprechen von Active Record pattern. Bitte siehe meine Antwort unten.
- Seine interessant, dass alle Antworten bisher, davon ausgehen, die Nutzung einer Datenbank. Ich weiß nicht, dass das Datenmodell bezieht sich notwendigerweise auf Datenbanken. Einige Programme, auch große mit den großen Architekturen verwenden Sie nicht eine Datenbank auf die alle, einige nicht einmal die Persistenz der Daten. So bedeutet dies, dass Sie nicht Daten-Modell. Ich meine das nicht genommen werden unsanft, aber es macht mich Frage mich, wie dies gilt auch für Anwendungen im Allgemeinen und nicht nur diejenigen, die funktionieren, nutzen Sie eine Datenbank...
- diese Frage ist zu MVC - also es bedeutet, dass es eine Daten-Modell. Aber es nicht bedeutet, die Existenz einer Datenbank, nur, dass mindestens eine Datenquelle vorhanden ist (es könnte sein, eine xml-Datei, zum Beispiel, eben wie ich sagte, auf meine Antwort unten).
Du musst angemeldet sein, um einen Kommentar abzugeben.
Business-Modelle bestehen aus, wie der Fluss der Daten bewegt sich in die Funktionen eines Unternehmens. Dies bedeutet nicht, nehmen Sie die Daten-Modell berücksichtigt, aber hilft Anleitung, wie die Daten gespeichert werden.
Daten Modelle mit den Daten im Hinterkopf - wo die Logik des Geschäftsmodells basiert auf Prozesse/Verfahren/nur der Lauf der Dinge, wie Sie sind gemacht, das Datenmodell ist so konzipiert, um die Struktur der Daten in den meisten normalisiert Weise möglich, dass auf die Bedürfnisse der business-Modell.
"Business Model" und "Data Model" können sowohl als sub-Ebenen der "M" - Stufe, in einer MVC-Anwendung. Sie beide beziehen sich auf das speichern und laden von Daten. Der Unterschied ist, dass die erste ist näher an der Art und Weise Sie die Anforderungen und Funktionalitäten werden gesehen durch den end-user, und das zweite ist näher an low-level-Datenbank-manipulation.
Dem Datenmodell Ebene ist immer mehr abhängig von der konkreten Art und Weise, dass die Daten persistiert über eine Anwendung. Ausgehend von der Datenbank (oder was auch immer ist Ihre konkrete Art und Weise der anhaltenden Daten - es könnte sein, flat-files, oder XML), ist es die erste, am wenigsten abstrakte software-Ebene. Zum Beispiel, wenn Sie den Oracle-RDBMS auf eine Anwendung, die Daten-Modell ist, wo Sie würde alle Oracle-Besonderheiten, wie bestimmte SQL-Anweisungen, Verbindung usw. Das ist auch der Ort, zu implementieren, atomic data manipulation (CRUD-SQL-Anweisungen, zum Beispiel). Natürlich gibt es Möglichkeiten, um dieses tier weniger abhängig von einem bestimmten RDBMS, wie einige Art von ORM-Bibliothek, wie Hibernate (Java), NHibernate (.NET) oder Doctrine (PHP).
So "low level", das Datenmodell sollte NICHT verwendet werden, die direkt von dem rest der Anwendung. Dies ist die Rolle des Geschäftsmodells.
Business Modell ist in einem oberen abstrakten Ebene. Es implementiert die services kapselt alle funktionalen Anforderungen von der Anwendung benötigt werden.
Das Geschäftsmodell sollte nicht abhängig sein von einer bestimmten RDBMS - es sollte das Datenmodell um diese Arbeit zu tun. Ein weiterer Unterschied ist, dass es macht weniger präzise Methoden - nicht CRUD-Sachen, aber mehr komplexen, business-abhängige Funktionalität. Natürlich sollte es auch nicht sein, abhängig von der präsentationsebene (views und Controller).
Zum Beispiel, eine Methode, die Veränderungen des Gehalts der einzelnen Mitarbeiter, basierend auf einer wörtlichen Wert, wahrscheinlich gehört das Daten-Modell (unter Berücksichtigung, dass eine solche Funktionalität ist nicht zulässig, die end-Benutzer). Aber eine Methode zur Erhöhung aller Gehälter auf einen bestimmten Prozentsatz wäre sicherlich gehören zum Geschäftsmodell (und es könnte Durchlaufen alle Mitarbeiter ein, und verwenden, ist Erstens, dass "einzelne Mitarbeiter aktualisieren", die Daten-Modell-Methode zu implementieren, die von dieser Regel, zum Beispiel).
Aber halten Sie im Verstand dies ist eine "durch-das-Buch -" Beschreibung der realen Welt Szenarien sind anders. Und manchmal haben wir keine Notwendigkeit, zwei verschiedene Ebenen - die ActiveRecord-pattern, zum Beispiel, kann verwendet werden, sowohl als Daten-Model-Klasse und eine Business class. In diesem Fall würden Sie vermischen beide Ebenen zu einer einzigen - aber ich würde definitiv nicht empfehlen, diesen Ansatz auf komplexere Szenarien.
Das Modell im MVC-Implementierung ist oder sein sollte, das Geschäftsmodell.
Business-Modell beschreibt das Verhalten und die Attribute der Entitäten des business, die für den Antrag relevant sind. Wenn Sie code, die die Entitäten werden Klassen und das Verhalten und die Attribute werden am Ende als Methoden und Eigenschaften dieser Klassen beziehungsweise.
Muss die Anwendung irgendwo zum speichern von Informationen. Wenn der Speicher waren Grenzenlos, wir würden nie Stromausfälle haben und der OS würde müssen nie neu gestartet wird, wird das business-Modell ausreichen würde. In der realen Welt jedoch, die wir brauchen, um zu speichern die Eigenschaften der Klassen irgendwo, wo Sie überleben können, die Anwendung und/oder den computer Herunterfahren.
Und so das Geschäftsmodell braucht und nutzt Daten eines Typs. Die Art und Weise diese Daten speichern organisiert ist, ist das Datenmodell. Wie in den meisten Fällen einer relationalen Datenbank ist das speichern von Daten der Wahl, das Datenmodell ist in der Regel das design der relationalen Datenbank.
Während ein Daten-Modell kann auf einer logischen Ebene und dann gleicht ein OO-business-Modell, das eng in diesem Zusammenhang sind wir in der Regel reden über eine technische Implementierung des logischen Modells. (Ein wichtiger Unterschied: logische Modelle ermöglichen die M-N Beziehungen zwischen den Tabellen der normierten technischen Modell wird eine link-Tabelle ist, die eine N-1-Beziehung mit den beiden ursprünglichen Tabellen).
OO-Natur des Geschäftsmodells nicht direkt zuordnen zu einer normalisierten Tabelle und Spalte design. ORM (Object - Relational - Mapping -) Bibliotheken werden oft verwendet, um anzeigen von Klassen, die Attribute zu den Tabellen und Spalten in der relationalen Datenbank.
Als business-Modell ist mit einer Daten speichern und somit eine Daten-Modell, und zusammen umfassen Sie das Modell in eine MVC-Implementierung, die Unterscheidung zwischen Ihnen oft verwischt. Ich denke, es ist sehr viel Wert zu halten, Ihre separaten Rollen klar im Kopf. Es hilft bei der Entscheidung, wo Logik gehen sollte.
Beispielsweise, im Gegensatz zu rsenna Antwort, ich würde Inhalte, die ändern das Gehalt für einen einzelnen Mitarbeiter ist noch eine Funktion des Geschäftsmodells, auch wenn es zu verändern, um einen Literalwert, weil das Geschäftsmodell definieren können alle Arten von checks and balances -, Validierungs-und andere business-Regeln zu ändern Gehälter. Für examply ist das Geschäft haben könnte Regeln, dass kein Gehalt ändern kann um mehr als x Prozent, kann nie mehr als die CEO ' s Gehalt, konform mit den Vorschriften der Union, etc.
Obwohl Datenbank-zentrierte Entwickler-und viele dba ' s nicht Zustimmen wird, diese Art von Regeln gehören in die business-Modells nicht in den Daten-Modell. DBa 's lieber, Sie in das Daten-Modell, vielleicht, weil das business-Modell ist in der Regel umgesetzt in irgendeiner Art von Programmiersprache und das Datenmodell in die Datenbank und den dba' s halten sich gerne Ihre Datenbanken nett und gültig und konsistent sind.
Ich würde sagen, die Regeln sind noch immer Teil des Geschäftsmodells, nicht das Daten-Modell, aber natürlich können Sie immer wählen, um Sie umzusetzen in die im Trigger und gespeicherte Prozeduren (wie auch). Wo die Regeln der business-Modell umgesetzt werden, ist eine Frage der..., sowie Umsetzung, detail.