ViewModel -> Model: кто отвечает за логику персистентности? - PullRequest
Новая
       25

ViewModel -> Model: кто отвечает за логику персистентности?

1 голос
/ 16 декабря 2010

в моем приложении ASP MVC 2 я следую строго типизированному шаблону представления с конкретными моделями представления.

Я являюсь моим приложением viewmodels являются ответственными за преобразование между моделями и viewmodels .
Мои viewmodels У меня есть статическая функция ToViewModel(...), которая создает новая модель для соответствующей модели. Пока что я в порядке с этим.

Когда я хочу отредактировать модель, я отправляю созданную модель просмотра по проводам и применяю изменения к модели. Для этого я использую статический метод ToModel(...) (также объявленный в модели представления). Вот заглушки для уточнения: 

public class UserViewModel
{
    ...
    public static void ToViewModel(User user, UserViewModel userViewModel)
    {
        ...
    }

    public static void toModel(User user, UserViewModel userViewModel)
    {
        ???
    }
}

Итак, теперь моя «проблема»: Некоторые модели являются сложными (больше, чем просто строки, целые, ...). Таким образом, логика постоянства должна быть помещена куда-нибудь .
(С логика персистентности я имею в виду решения Wheater для создания новой записи в БД или нет, ... не просто грубый CRUD - я использую репозитории для этого)

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

Можете ли вы дать мне подсказку?

Lg
warappa

Ответы [ 2 ]

0 голосов
/ 16 декабря 2010

В наших проектах MVC у нас есть отдельное место для конвертеров.

У нас есть два типа преобразователей: IConverter и ITwoWayConverter (немного больше, чем это, но я сохраняю это простым).

ITwoWayConverter содержит два основных метода ConvertTo и ConvertFrom, которые содержат логику для преобразования модели в модель представления и наоборот.

Таким образом, вы можете создавать специальные конверты для переключения между типами, такими как: 

public class ProductToProductViewModelConverter : ITwoWayConverter<Product,ProductViewModel>

Затем мы вводим соответствующие преобразователи в наш контроллер по мере необходимости.

Это означает, что ваше преобразование из одного типа в другой не ограничивается одним преобразователем (хранится внутри модели или где-либо еще).

0 голосов
/ 16 декабря 2010

Warappa - мы используем как шаблон хранилища, так и модели представления.

Однако у нас есть два дополнительных слоя:

  • service
  • task

Сервисный уровень имеет дело с такими вещами, как сохраняются реляционные данные (модели сложных объектов) и т. Д. Уровень задач имеет дело с причудливыми linq-корреляциями данных и любыми дополнительными манипуляциями, которые требуются для1013 * представить правильные данные для модели представления.

Помимо этого, у нас также есть класс «фильтров» для каждой сущности.Это позволяет нам целенаправленно использовать методы расширения для каждого класса.

simples ...:)

...