2013-11-01 3 views
5

Я следую шаблону репозитория с уровнями обслуживания в моем проекте. Для каждого представления я собираюсь создать viewmodel.Входные данные ввода уровня сервиса ASP.NET MVC

То, что я смущен, заключается в том, что, если сервисный уровень напрямую обращается к объектам домена и возвращает их контроллеру, или я должен использовать DTO. Если я должен использовать DTO, где разместить их в архитектуре проекта?

спасибо.

ответ

9

Сервисный уровень отвечает за преобразование (преобразование) объектов Dto и объектов домена путем реализации надлежащего business logic.

Ваши объекты DTO должны использоваться в контроллерах и службах.

DTO-х передаются между контроллером и услуг, на других объектах руки домена передаются между службой и Repository

контроллер не знает о домене и Repository не знает о DTO. Служба знает как DTO, так и Domain и преобразует их друг в друга с бизнес-правилами, такими как автомобиль между водителем и дорогой, например stackoverflow между вами и мной, как и все, абстракция ...

Следующий пример - пример. Рассмотрим, что каждое пространство имен является пакетом.

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

Если я отправляю CoffeeEntity на контроллер, а не GetCoffeeInDto, я нарушаю правила архитектуры? Мне кажется, что я переписываю объекты домена только для использования DTO. – SherleyDev

+0

Да, если вы отправляете сущность на контроллер, вы нарушаете архитектуру. Но вам не нужно использовать эту архитектуру, если ваш проект невелик, а ваш бизнес недостаточно сложный. Разделение объектов как Dto и Entity - это различие между информацией и данными. Что касается принципа разделения интересов, игра с данными на слое данных и игра с информацией в слое представления рассматриваются как отдельные проблемы и сохраняются с использованием отдельных реализаций классов. – mecek

+0

+1 Отличный ответ. @SherleyDev Посмотрите здесь: http://stackoverflow.com/a/21569720/654708 для получения более подробного ответа. Обратите внимание, что не обязательно привязывать контроллер к вашим моделям домена; для небольших проектов создание DTO можно считать излишним. – GFoley83