Search results matching tag 'Gastbeitrag'

Gastbeitrag: MVP oder MVVM? Was gehoert wohin?

Peter Bucher — Wed, 06 Feb 2013 19:14:00 GMT

Einleitung

Ein Kollege von mir hat sich intensiv mit den Designpatterns MVP und MVVM auseinandergesetzt und unter anderem auch mit mir diskutiert.
Da ich seine Gedanken sehr interessant fand, kam uns schlussendlich die Idee, diese als Gastbeitrag in meinem Blog zu veröffentlichen.
Der Hauptgedanke dieser Veröffentlichung ist Entwirrung und das Einholen von Feedback zu diesem Thema aus meiner Leserschaft.

In diesem Sinne wünsche ich euch viel Spass mit dem Gastbeitrag und wir freuen uns auf reichliches Feedback.

Gastbeitrag

Die Designpatterns MVP (Model - View - Presenter) und MVVM (Model - View - ViewModel) sind Designpatterns für die Strukturierung und Trennung von Daten, Ansicht und Presentationslogik.
Ich habe mich im Zusammenhang mit der Entwicklung eines Applikationsframework für Businessanwendungen damit beschäftigt und schaute dazu im Internet verschiedene Implementierungen und Blogeinträge an. Mein Verständnis hatte sich dabei nicht vergrössert, sondern erstmal mehr Verwirrung geschaffen:

Was ist der Unterschied zwischen einem Model und einem Entity?
Was ist ein Presenter?
Was ist Presentationslogik?
Was ist der Unterschied zwischen Presenter und ViewModel?

Ich versuche möglichst knapp meine Ansicht mitzuteilen und auch Beispiel-Code anzubieten. Im folgenden Beispiel verwende ich das MVP-Pattern:

Entity / Model:

Ein Entity enthält Daten wie Name, Adresse und Ort usw. z.B. eines Customers:

public class CustomerEntity { public int CustomerId { get; set; } public string Name { get; set; } public string Address { get; set; } public string Location { get; set; } }

Ein Model enthält wiederum ein oder mehrere Entities (z.B. ein zu editierender Customer oder ein Suchergebnis).

Das Model stellt die dazugehörenden Methoden, um Entities zu laden, zu suchen oder abzuspeichern zur Verfügung.
Zusätzlich darf im Model der Status des Views gespeichert werden, z.B. IsCustomerSelected, um gebunden mit der Eigenschaft IsEnabled eines Button zu unterscheiden, ob ein Customer im ListView der Ansicht selektiert wurde und somit editiert werden kann oder nicht.
Eigenschaften wie die eines Customers sollten meiner Meinung nach nicht im Model zur Verfügung gestellt werden, sondern getrennt in einem separaten Entity, obwohl dies in den meisten Artikel bezüglich MVP / MVVM genau anders dargestellt wird.
Im MVVM-Pattern wird von Microsoft empfohlen, die Daten sogar im ViewModel (Presenter) einzufügen; diese Mischung zwischen einerseits Daten und Presentationslogik steht die Möglichkeit entgegen, ableitbare Model-BasisKlassen für Daten und Basisklassen für Presentationslogik zu entwickeln.

In der Basisklasse für Modelle sollte INotifyPropertyChanged implementiert werden, damit die Ansicht, falls mit DataBinding gearbeitet, aktualisiert wird.

public class Model : INotifyPropertyChanged { public void OnPropertyChanged(string propertyName) { if (this.PropertyChanged != null) { this.PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); } } public event PropertyChangedEventHandler PropertyChanged; } public class EditCustomerModel : Model { private CustomerEntity _customer; public void NewCustomer() { this.Customer = new CustomerEntity(); } public void EditCustomer(int customerId) { // Code, um Customer Entity zu laden // this.Customer = ... } public CustomerEntity Customer { get { return _customer; } set { _customer = value; this.OnPropertyChanged("Customer"); } } } public class SearchCustomerModel : Model { private IEnumerable<CustomerEntity> _customers = new List<CustomerEntity>(); private CustomerEntity _selectedCustomer = null; public CustomerEntity SelectedCustomer { get { return _selectedCustomer; } set { _selectedCustomer = value; // Aktualisiert DataBindings für SelectedCustomer this.OnPropertyChanged("SelectedCustomer"); // Aktualisiert die IsEnabled Eigenschaft des Buttons this.OnPropertyChanged("IsCustomerSelected"); } } public IEnumerable<CustomerEntity> Customers { get { return _customers; } set { _customers = value; // OnPropertyChanged aktiviert das updaten der Liste in der Ansicht, falls DataBinding verwendet wurde this.OnPropertyChanged("Customers"); } } public void LoadAllCustomers() { // Code, um alle CustomerEntities zu laden // this.Customers = ... } public void SearchCustomers(string text) { // Code, um CustomerEntities zu laden } public bool IsCustomerSelected { get { return this.SelectedCustomer != null ? true : false; } } }

View:

Die Views hier als Code bereitzustellen, sprengt den Rahmen dieses Artikels. Ich bitte hierzu die Vorstellungskraft des Lesers zu bemühen, um sich die Views für EditCustomerView und SearchCustomerView vorzustellen.
Das Databinding für ListView und SearchCustomerModel.Customers, sowie den Edit Button mit IsCustomerSelected zu verknüpfen, können wir uns vorstellen.
Im View ist eine Referenz auf den Presenter zu setzen, um auf die Methoden des Presenters zugreifen zu können.

public partial class SearchCustomerView : Page { private SearchCustomerPresenter Presenter { get; set; } public SearchCustomerView() { InitializeComponent(); // Neue Presenter Instanz this.Presenter = new SearchCustomerPresenter(); // Model binden mit DataContext des View für DataBinding this.DataContext = this.Presenter.Model; } private void searchButton_Click_1(object sender, RoutedEventArgs e) { this.Presenter.SearchCustomers(this.searchTextBox.Text); } private void loadAllCustomers_Click_1(object sender, RoutedEventArgs e) { this.Presenter.LoadAllCustomers(); } }

Presenter / ViewModel:

Persönlich finde ich die Namensgebung Presenter besser als ViewModel; so kann besser zwischen Model-, View- und Presenterklassen unterschieden werden.
Im Presenter ist die Presentationslogik. Der Presenter delegiert meistens nur vom View zum Model.
Microsoft empfiehlt bezüglich MVVM das ViewModel (Presenter) als DataContext im View zu setzen - dies im Zusammenhang mit Commands, die sich im Presenter befinden und mit Steuerelementen des Views gebunden werden; in meinem Beispiel setze ich als DataContext das Model.

Ich meine, dass das MVVM Schema im Sinne von Microsoft hinterfragt werden muss, denn Microsoft trennt im MVVM-Schema nicht klar zwischen Model und Presenter oder besser ausgedrückt zwischen Daten und Presentation. Das Model klar vom ViewModel (Presenter) zu trennen, ist ja aber gerade die ursprüngliche Idee dieser Pattern MVP und MVVM.

Meiner Ansicht nach gehören Daten ins Model und nicht in die Presentationslogik: deshalb setze ich das Model als DataContext im View und nicht das ViewModel (Presenter).

In meinem Beispiel habe ich eine einfache Implementierung verwendet, ohne Kommunikation zwischen Presenter und View:

public class EditCustomerPresenter { public EditCustomerPresenter() { this.Model = new EditCustomerModel(); } public void NewCustomer() { this.Model.NewCustomer(); } public void EditCustomer(int customerId) { this.Model.EditCustomer(customerId); // Falls ohne DataBinding per xaml: // UpdateView(); } public EditCustomerModel Model { get; set; } } public class SearchCustomerPresenter { public SearchCustomerPresenter() { this.Model = new SearchCustomerModel(); } public SearchCustomerModel Model { get; set; } public void SearchCustomers(string text) { this.Model.SearchCustomers(text); } public void LoadAllCustomers() { this.Model.LoadAllCustomers(); } }

Um nun an einem ganz kleinen Beispiel zu veranschaulichen, was Presentationslogik ist, erweitere ich die SearchCustomers Methode etwas:

public void SearchCustomers(string text) { this.Model.SearchCustomers(text); MessageBox.Show(String.Format("{0} Kunde(n) gefunden.", this.Model.Customers.Count())); }

Wo sonst sollte die MessageBox die Anzahl der Ergebnisse anzeigen, wenn nicht in der Presentationslogik des Presenters? Diese Info soll natürlich nur die Presenationslogik veranschaulichen; solche unnötigen Infos sollten in Businessapplikationen vermieden werden.

Auch erfahrene Entwickler brauchen etwas Zeit, wenn sie sich zum ersten Mal mit MVP und MVVM beschäftigen, um diese Patterns zu verstehen. Das beste Verständnis habe ich persönlich beim Implementieren eigener MVPs gewonnen und kann das nur weiterempfehlen.

Hier eine fragwürdige Implementierung des MVVM:

http://msdn.microsoft.com/de-de/magazine/dd419663.aspx

Hierzu einige Äusserungen:
Erstmal vorne weg: In diesem Artikel scheint ein Model gar nicht erst vorzukommen; die Daten wurden in das ViewModel, bzw. in den Presenter, also in die Presentationlogik hineingesetzt. Deshalb wurde dort auch die Schnittstelle INotifyPropertyChanged implementiert, die klar ins Model gehört.

Fazit:

Der MVP Pattern trennt klar Model und Presenter; der MVVM Pattern scheint diese Trennung nicht mehr anzustreben. Auch wenn wir uns vorstellen, Models zu entwickeln, die mit Hilfe von Generics standardmässig Eigenschaften zur Verfügung stellen, scheint mir die Trennung zwischen Model und Presenter im Sinne der Klassenhierarchie wichtig; So würden wir wohl Basisklassen einerseits für Daten-Modelle und andererseits für Presentationslogik erstellen und kaum beides in eine ViewModel-Klasse zwängen.
Wichtig ist für mich auch die Trennung zwischen Entity und Model.
Der MVVM Pattern scheint einige sinnvolle Eigenheiten des MVP Pattern über Bord zu schmeissen (z.B. klare Trennung zwischen Model und Presenter). Die aufwendige Verwendung von Commands sehe ich nicht als existentielle Erweiterung beim MVVM; ich sehe die MVP Implementierung als einfacher und klarer an.

Stefan Werdenberg, IntegralFramework

Vom Visual Studio zum Wix Setup in 5 einfachen Schritten

Jürgen Gutsch — Tue, 08 Mar 2011 11:13:00 GMT

Der folgende Beitrag ist ein Gastbeitrag von Sebastian Seidel, Gründer und Inhaber der Firma Cayas (http://www.cayas.de/). Vor einigen Monaten hatte ich per Twitter die Frage gestellt, wie man aus einem herkömmlichen Visual Studio Setup-Projekt ein Windows Installer XML-Projekt (WiX) erstellt. Falls es weitere Fragen zu WiX gibt, ist Sebastian über seine Website oder per Twitter zu erreichen.

Von meiner Seite ein großes Dankeschön an Sebastian, dass er sich die Mühe gemacht hat hier eine Anleitung zur Migration zu schreiben und hier zu veröffentlichen :-)

--------------

Vom Visual Studio zum Wix Setup in 5 einfachen Schritten

Vor einiger Zeit wurde über Twitter die Frage gestellt, wie man ein bestehendes Visual Studio Setup-Projekt (vd-proj) in ein Windows Installer XML-Setup (wixproj) migriert. Ich möchte an dieser Stelle einen möglichen Weg aufzeigen, wie man dies erreichen kann.

Schritt 1: Vorbereitung

Um die Schritte nachvollziehen zu können benötigt ihr die aktuelle Version von Wix, die ihr unter http://wix.sourceforge.net herunterladen könnt. In diesem Artikel verwende ich die aktuelle Version 3.5 des Windows Installer XML Toolsets.

Nach dem alles installiert und ins Visual Studio integriert ist solltet ihr folgendes Bild haben, wenn ihr ein neues Projekt erstellen wollt.

Beginnen wir nun also mit der Konvertierung.

Schritt 2: altes Setup erstellen

Im eigentlichen ersten Schritt bleibt alles wie gehabt. Ihr erstellt also euer Setup über die VS-Setup Solution. Das Ergebnis des Builds ist eine Setup.exe und ein Setup.msi-Paket.

Schritt 3: altes Setup dekompilieren

Für das unter Schritt 2 erstelle msi-Paket erstellen wir uns einen Ordner WixTransform auf dem Desktop und kopieren unser msi-File dort hin. Anschließend öffnen wir eine Command-Box (cmd) und wechseln in das Installationsverzeichnis vom Windows Installer XML. Darin befindet sich eine Datei namens Dark.exe, die wir mit dem Parameter -h aufrufen. Im folgenden Bild sieht man einen Teil der ausgegebenen Parameter, die mit Dark verwendet werden können.

Uns interessiert nur der -o[ut] Parameter mit dem wir angegeben können, wohin wir den Output umgeleitet haben möchten.

Hinweis: Dark kann nicht mit Leerzeichen im Pfad umgehen. Ich behelfe mir damit, dass ich mein msi-Paket in einen Ordner auf dem Desktop kopiere und alle Leerzeichen entferne.

Wir haben nun alle Vorbereitungen erledigt und können mit der eigentlichen Konvertierung beginnen. Dazu geben wir folgenden Aufruf ein:

Dark.exe -nologo -o C:\Users\Sebastian\Desktop\WixTransform\mySetup.wxs C:\Users\Sebastian\Desktop\WixTransform\Setup.msi

Wenn der Vorgang erfolgreich durchgeführt wurde, finden wir in unserem Ordner - bei mir WixTransform - nun eine mySetup.wxs, die den kompletten Aufbau unseres alten Setups enthält.

Schritt 4: Neues Setup-Projekt erstellen

Wir haben in den vorherigen Schritten unser Setup erstellt und es anschließend wieder in eine Windows Installer XML Source Datei konvertiert. Im letzten Schritt geht es nun darum diese zu nutzen. Wir wechseln dazu ins Visual Studio und fügen unserer Solution ein weiteres Projekt hinzu. Dieses Mal allerdings eins vom Typ Windows Installer XML Setup Projekt.

Unser leeres Projekt besteht lediglich aus der Product.wxs, welche wir löschen bzw. durch unsere mySetup.wxs ersetzen.

Schritt 5: Aufräumen

Damit unser Setup nun wieder ordnungsgemäß erstellt werden kann müssen wir unsere mySetup.wxs noch aufräumen. Die folgende Beschreibung gibt meine Vorgehensweise wieder. Sicherlich gibt es verschiedene Wege das Ziel zu erreichen. Wenn Ihr also einen optimaleren Weg gefunden habt, so lasst es mich doch wissen, in dem Ihr einfach ein Kommentar schreibt.

Fangen wir also an in dem wir unsere mySetup.wxs von oben nach unten durchgehen. Zuerst entferne ich alle <Binary>, <CustomAction>, <CustomTable> und <Property> Elemente. Ausgenommen sind natürlich die CustomActions, die ich eventuell auch in meinem ursprünglichen VS-Setup eingebunden hatte sowie die folgenden und meine eigenen Properties:

<Property Id="ARPHELPTELEPHONE" Value="1234 1234567" /> <Property Id="ARPCONTACT" Value="Sebastian Seidel" /> <Property Id="ARPCOMMENTS" Value="Mein Produktname" /> <Property Id="ARPURLINFOABOUT" Value="http://www.cayas.de" /> <Property Id="ARPPRODUCTICON" Value="IconSource" />

Anschließend ändere ich die kryptischen <Component> IDs zu aussagekräftige ab. Da ich meine Dialoge in einer separaten Datei erstellt habe, lösche ich auch das <UI> XML-Node. Wer möchte kann an dieser Stelle noch Einfluss auf die Dialoge nehmen und diese entsprechend anpassen.

Zu guter Letzt entferne ich noch alle Nodes, die ein Sequence enthalten. Auch das kann wieder jeder halten wie er möchte. Grundsätzlich kann man mit diesen Sequenzanweisungen viel Einfluss auf das Ausführungsverhalten des Setups nehmen.

In einem letzten Durchgang passe ich dann alle Source-Elemente an, damit diese wieder die richtigen Dateien referenzieren.