Куда идут методы преобразования классов - PullRequest
Новая
       1

Куда идут методы преобразования классов

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

Многие мои классы в конечном итоге нуждаются в функциях конвертирования.

  • DataRow -> Конвертеры объектов
  • ViewModel <-> Конвертеры моделей

У меня вопрос, где должны жить функции?

Вариант 1: Внутри исходного класса 

public class Employee
{
  public EmployeeViewModel ToViewModel() {}
}

var vm = myEmployee.ToViewModel()

Вариант 2: Внутри класса назначения 

public class EmployeeViewModel
{
  public static EmployeeViewMOdel FromModel() {}
}

var vm = EmployeeViewModel.FromModel(myEmployee);

Вариант 3: Внутри преобразователя 

public class EmployeeModelViewModelConverter
{
  public static EmployeeViewModel ConvertToViewModel(Employee) {}
}
var vm = new EmployeeModelViewModelConverter.ConvertToViewModel(myEmployee);

Вариант 3 представляется наиболее чистым за счет того, что вокруг лежат тонны классов преобразователей и тонны статических функций или тонны инициализации / впрыска IOC. Он также имеет самый уродливый синтаксис, или вам нужно добавить еще один класс, используя расширения.

Пояснение: Я говорю не только о классах ViewModel / Model, но обо всем, что вам нужно для преобразования одного класса в другой. В качестве другого примера, у меня есть система рендеринга, в которой объекты часто нужно преобразовать в рендеринг примитивов.

Ответы [ 4 ]

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

Я полагаю, что Принцип единой ответственности предполагает № 3, свой собственный класс конвертера.

РЕДАКТИРОВАТЬ: Если вам нужно это в отдельном методе, то я бы придерживался того, что я сказал выше. Но у @kyoryu есть верная точка зрения о ViewModel, однако я согласен, только если Модель передается как аргумент в конструкторе ViewModel, а не как отдельный метод.

1 голос
/ 11 августа 2010

Возможно, вы захотите рассмотреть что-то вроде AutoMapper . Хотя он изначально был разработан для отображения между объектами DTO и ViewModel, он очень мощный и может удалить весь этот код отображения без дополнительных затрат на множество дополнительных классов.

1 голос
/ 11 августа 2010

Я бы, вероятно, сказал бы вариант 2. Поскольку весь смысл наличия ViewModel состоит в том, чтобы обеспечить логический «слой перевода» между базовой моделью и требованиями View, кажется, что это во многом свойствоViewModel.

Вариант 1 (на мой взгляд) исключен, поскольку он разрывает разделение между моделью и моделью представления (учтите - теоретически существует несколько моделей ViewModel, которые могут потребоваться для просмотра данных сотрудников, и все они могутбыть другим).

Вариант 3 также является разумным и, безусловно, дает вам еще большее разделение.Я не совсем уверен, что это необходимо, так как ViewModel все еще будет иметь сотрудника.

0 голосов
/ 11 августа 2010

Это может быть одна из тех ситуаций "личного предпочтения".Каждый из ваших вариантов реализован в библиотеке .NET, поэтому мы можем предположить, что с точки зрения Microsoft нет четкого передового опыта:

  • someCollection.ToArray ()
  • DateTime.Parse ()
  • Convert.ToInt32 ()
...