2013-11-01 14 views
5

Ich befolge das Repository-Muster mit Service-Schichten in meinem Projekt. Für jede Ansicht werde ich ein Viewmodel erstellen.ASP.NET MVC Service Layer Eingabe Ausgabedaten

Was ich verwirrt bin, ist, dass, wenn die Service-Schicht direkt auf Domänenobjekte zugreifen und sie an den Controller zurückgibt, oder sollte ich DTOs verwenden. Wenn ich DTOs verwenden sollte, wo in die Projektarchitektur?

Vielen Dank.

Antwort

9

Die Serviceschicht ist für das Mapping (Konvertieren) von Dto-Objekten und Domänenobjekten zuständig, indem sie die richtige business logic implementiert.

Ihre DTO-Objekte sollten in Controllern und Diensten verwendet werden.

DTO werden übertragen zwischen Steuerung und Service auf der anderen Seite Domain-Objekte werden zwischen Dienst und Repository wissen

-Controller nicht über Domain und Repository nicht wissen, über DTO übertragen. Service kennt sowohl DTO und Domain und konvertiert sie gegenseitig mit Geschäftsregeln wie ein Auto zwischen Fahrer und Straße, wie stackoverflow zwischen Ihnen und mir, wie alles, Abstraktion ...

Der folgende Code ist ein Beispiel. Betrachten Sie jeden Namespace als ein Paket.

namespace Controllers 
{ 
    using Services; 
    using DataTransferObjects; 

    public class CoffeeController 
    { 
     public ICoffeeService CoffeeService { get; set; } 

     public JsonResult GetCoffee(GetCoffeeInDto inDto) 
     { 
      var result = CoffeeService.GetCoffee(inDto); 
      return JsonResult(result); 
     } 

     public JsonResult SaveCoffee(SaveCoffeeInDto inDto) 
     { 
      var outDto = CoffeeService.SaveCoffee(inDto); 
      return JsonResult(outDto); 
     } 
    } 
} 

namespace Services 
{ 
    using DataTransferObjects; 
    public interface ICoffeeService 
    { 
     GetCoffeeOutDto GetCoffee(GetCoffeeInDto inDto); 
     SaveCoffeeOutDto SaveCoffee(SaveCoffeeInDto inDto); 
    } 
} 

namespace Services.Impl 
{ 
    using Services; 
    using Repository; 
    using DataTransferObjects; 
    using Domain; 

    public class CoffeeService : ICoffeeService 
    { 
     public ICoffeeRepository CoffeeRepository { get; set; } 
     public GetCoffeeOutDto GetCoffee(GetCoffeeInDto inDto) 
     { 
      var entity = CoffeeRepository.Get(inDto.Id); 
      return new GetCoffeeOutDto {Id = entity.Id, Name = entity.Name}; 
     } 

     public SaveCoffeeOutDto SaveCoffee(SaveCoffeeInDto inDto) 
     { 
      var entity = new CoffeeEntity {Name = inDto.Name}; 
      CoffeeRepository.Save(entity); 
      return new SaveCoffeeOutDto {Id = entity.Id}; 
     } 
    } 
} 

namespace Repository 
{ 
    using Domain; 
    public interface ICoffeeRepository 
    { 
     CoffeeEntity Get(int id); 
     void Save(CoffeeEntity coffeeEntity); 
    } 
} 

namespace Repository.Impl 
{ 
    using Repository; 
    using Domain; 

    public class CoffeeRepository:ICoffeeRepository 
    { 
     public CoffeeEntity Get(int id) 
     { 
      //get entity from db 
      throw new System.NotImplementedException(); 
     } 

     public void Save(CoffeeEntity coffeeEntity) 
     { 
      //insert entity into db 
      throw new System.NotImplementedException(); 
     } 
    } 
} 

namespace DataTransferObjects 
{ 
    public class SaveCoffeeInDto 
    { 
     public string Name { get; set; } 
    } 

    public class SaveCoffeeOutDto 
    { 
     public int Id { get; set; } 
    } 

    public class GetCoffeeInDto 
    { 
     public int Id { get; set; } 
    } 

    public class GetCoffeeOutDto 
    { 
     public int Id { get; set; } 
     public string Name { get; set; } 
    } 
} 

namespace Domain 
{ 
    public class CoffeeEntity 
    { 
     public int Id { get; set; } 
     public string Name { get; set; } 
    } 
} 
+0

Wenn ich CoffeeEntity an den Controller anstelle von GetCoffeeInDto sende, breche ich Regeln der Architektur? Es scheint mir, Domänenobjekte neu zu schreiben, nur um DTOs zu verwenden. – SherleyDev

+0

Ja, wenn Sie eine Entität an den Controller senden, verletzen Sie die Architektur. Aber Sie müssen diese Architektur nicht verwenden, wenn Ihr Projekt nicht groß ist und Ihr Geschäft nicht kompliziert genug ist. Bei der Trennung von Objekten als Dto und Entity geht es um die Unterscheidung zwischen Informationen und Daten. Im Hinblick auf das Prinzip der Trennung von Belangen wird das Spielen mit Daten in der Datenschicht und das Spielen mit Informationen in der Darstellungsschicht als getrennte Belange betrachtet und unter Verwendung von separaten Klassenimplementierungen gehalten. – mecek

+0

+1 Ausgezeichnete Antwort. @SherleyDev Schauen Sie hier: http://Stackoverflow.com/a/21569720/654708 für eine detailliertere Antwort. Beachten Sie, dass es nicht von Natur aus schlecht ist, Ihren Controller an Ihre Domänenmodelle zu binden. Bei kleineren Projekten kann das Erstellen von DTOs als Overkill betrachtet werden. – GFoley83

Verwandte Themen