In meiner Lösung habe ich zwei Projekte.
Projekt 1 (Core) Mapping SQL zu DTO mit Dapper
Projekt 2 (WebUI - ASP.NET MVC 4) Hier verwende ich ein ViewModel pro View.
Beispiele für einen Controller
[HttpGet]
public ActionResult Edit(int id)
{
// Get my ProductDto in Core
var product = Using<ProductService>().Single(id);
var vm = new ProductFormModel(product);
return View(vm);
}
Beispiele für ein ViewModel
public class ProductFormModel : BaseViewModel, ICreateProductCommand
{
public int ProductId { get; set; }
public int ProductGroupId { get; set; }
public string ArtNo { get; set; }
public bool IsDefault { get; set; }
public string Description { get; set; }
public string Specification { get; set; }
public string Unit { get; set; }
public string Account { get; set; }
public decimal NetPrice { get; set; }
public ProductFormModel(int productGroupId)
{
this.ProductGroupId = productGroupId;
}
public ProductFormModel(ProductDto dto)
{
this.ProductId = dto.ProductId;
this.ProductGroupId = dto.ProductGroupId;
this.ArtNo = dto.ArtNo;
this.IsDefault = dto.IsDefault;
this.Description = dto.Description;
this.Specification = dto.Specification;
this.Unit = dto.Unit;
this.Account = dto.Account;
this.NetPrice = dto.NetPrice;
}
public ProductFormModel()
{
}
}
Erläuterung: Ich werde meine DTOs in meinem Controller mithilfe einer Serviceklasse im Projekt (Core) abrufen. Dann erstelle ich mein ViewModel und übergebe das DTO an den Konstruktor in ViewModel. Ich kann diese Ansicht auch verwenden, um ein neues Produkt hinzuzufügen, da mein ViewModel einen leeren Konstruktor verwenden kann.
Hat jemand Erfahrung damit? Ich frage mich, ob ich auf diese Weise Probleme in der Zukunft haben werde, wenn das Projekt größer wird?
Ich weiß, das hat nichts mit Dapper zu tun. Aber ich möchte immer noch einen guten Weg, meine Lösung zu erklären.
Ich denke, Sie werden Ihren derzeitigen Ansatz nutzen können. Noch wichtiger: Beginnen Sie so und refactorieren Sie, wenn Sie Probleme im Zusammenhang mit Ihrem Objekt-Mapping-Code bekommen (anstatt zu viel darüber nachzudenken).
Eine weitere Möglichkeit zum Organisieren von Mapping-Logik, die ich manchmal verwende, ist die Verwendung von Erweiterungsmethoden. Auf diese Weise wird der Mapping-Code vom View-Modell selbst getrennt. Etwas wie:
public static class ProductMappingExtensions
{
public static ProductFormModel ToViewModel(this ProductDto dto)
{
// Mapping code goes here
}
}
// Usage:
var viewModel = dto.ToViewModel();
Ein weiterer Ansatz wäre die Verwendung eines Mapping-Frameworks wie AutoMapper - dies ist besonders dann sinnvoll, wenn Ihre Mapping-Logik einfach ist (viele 1: 1-Mappings zwischen Eigenschaften).
Aber noch einmal, starten Sie einfach und refactor, wenn Sie müssen .
Ich weiß, dass dies eine späte Antwort ist, aber vielleicht wird es jemandem in der Zukunft helfen.
Diese Art der Zuordnung zwischen Objekten bricht das 'S' der SOLID-Prinzipien, da die Verantwortung des ViewModels darin besteht, Daten in seinen Eigenschaften so vorzubereiten, dass sie von der Ansicht verwendet werden können und nichts anderes, daher sollten Mapping-Objekte nicht eingeschaltet sein es ist Verantwortlichkeiten.
Ein weiterer Nachteil dieser Methode besteht darin, dass sie auch das OO-Prinzip "Loose Coupling" durchbricht, da ViewModel stark mit Ihrem DTO gekoppelt ist.
Ich denke, selbst wenn wir uns im allerersten Schritt des Projekts befinden, gibt es einige wichtige OO-Prinzipien, die wir niemals brechen sollten. Daher ist die Verwendung von Mapper-Klassen, entweder automatisch (AutoMapper, ValueInjecter ...) oder manuell, definitiv besser.