Как правильно использовать DTO в этом случае? - PullRequest
Новая
       27

Как правильно использовать DTO в этом случае?

3 голосов
/ 08 августа 2010

У меня есть следующий класс домена: 

public class Product
{
    public virtual Guid Id { get; set; }
    public virtual string Name { get; set; }
    public virtual IList<Product> RelatedProducts { get; set; }
}

У меня есть следующий класс DTO: 

public class ProductDTO
{
    public ProductDTO(Product product)
    {
        Id = product.Id;
        Name = product.Name;
    }

    public Guid Id { get; private set; }
    public string Name { get; private set; }
}

У меня в службе есть следующий метод: 

public ProductDTO GetBySlug(string slug)
{
    Product product = productRepository.GetBySlug(slug);
    return (product != null) ? new ProductDTO(product) : null;
}

У меня в контроллере следующее действие: 

public ActionResult Details(string slug)
{
    ProductDTO viewModel = productService.GetBySlug(slug);
    return View("Details", viewModel);
}

Прочитав немного, я понял, что использовать DTO в качестве модели представления можно, так как текущий сценарий прост и понятен. Моя путаница возникает, когда данные, которые я хочу вернуть, становятся немного более сложными. Давайте предположим, что я также хочу вернуть список связанных продуктов в представление. Куда бы я добавил этот список?

Я прочитал, что DTO - это упрощенная версия сущности вашего домена, которая используется для передачи данных. Означает ли это, что общий список, содержащий соответствующие продукты, не должен быть разрешен внутри DTO? Ответ, который я получил до сих пор, говорит об этом. Как я могу получить соответствующие продукты на контроллер?

Один из вариантов:

Вместо того, чтобы возвращать ProductDTO в сервисе, я бы создал новый класс, содержащий ProductDTO и Список типов ProductDTO для связанных продуктов, и возвратил бы его из сервиса. Затем в контроллере я либо передаю новый класс представлению, либо создаю отдельную ProductViewModel, которая содержит ProductDTO и список типа ProductDTO для связанных продуктов, заполняет его и передает его представлению.

Это хорошая или плохая идея? Почему?

Спасибо

1 Ответ

2 голосов
/ 08 августа 2010

Я бы вообще не помещал список в DTO, потому что он там не принадлежит.И я также не уверен, что вы имеете в виду под «классом-оберткой».Все, что вам нужно, это список продуктов, и совершенно нормально, чтобы в сервисе был другой метод, который возвращает этот список.

Следовательно, у вас будет что-то вроде этого в вашем сервисе: 

public IList<ProductDTO> GetRelatedProducts(ProductDTO productDTO)
{
    ...

Самая важная идея модели представления (то, что выше называется service ) заключается в том, что она является посредником между пользовательским интерфейсом и бизнес-моделью.Другими словами: он координирует и объединяет бизнес-модель таким образом, который имеет отношение к пользовательскому интерфейсу.И если пользовательский интерфейс хочет список связанных продуктов в какой-то момент, то служба должна предоставить его.Это действительно так просто, и совершенно не имеет значения, имеет ли сама бизнес-модель эту концепцию.

HTH!Thomas

PS Если ваши DTO становятся больше, а ваши списки длиннее, вы можете подумать о введении другого (упрощенного) DTO только с именем и своего рода идентификатором, чтобы уменьшить количество ненужных данных, которые вы должны извлечь изхранилище.

...