Question

我的许多课程最终都需要转换功能。

DataRow - ＆gt;对象转换器
ViewModel＆lt; - ＆gt;模型转换器

我的问题是这些功能应该在哪里生效？

选项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类，而是您需要将一个类转换为另一个类的任何内容。作为另一个例子，我有一个渲染系统，其中对象通常需要转换为可渲染的基元。

Answer 1

我相信Single Responsibility Principle建议＃3，它自己的转换器类。

编辑：如果你需要一个单独的方法，那么我会坚持我上面所说的。但是@kyoryu有一个关于ViewModel的有效观点，但是，我只会同意Model在ViewModel构造函数中作为参数传递，而不是作为一个单独的方法。

Answer 2

我实际上可能会说选项2.因为拥有ViewModel的全部意义是在底层模型和View的需求之间提供逻辑“转换层”，它似乎非常属于视图模型。

选项1是（在我看来），因为它打破了Model和ViewModel之间的分离（考虑 - 理论上有多个ViewModel可能需要查看员工数据，而且它们可能都不同）。 / p>

选项3也是合理的，当然会给你更多的分离。我不完全确定它是必要的，因为ViewModel仍然可能有一个员工。

Answer 3

您可能需要考虑AutoMapper之类的内容。虽然它最初是为DTO和ViewModel对象之间的映射而开发的，但它非常强大，可以删除所有映射代码，而不会产生如此多的其他类的开销。

Answer 4

这可能是那些“个人偏好”情况之一。您的每个选项都在.NET库中实现，因此我们可以猜测从微软的角度来看并不是一个明确的最佳实践：

someCollection.ToArray（）
DateTime.Parse（）
Convert.ToInt32（）

类转换方法在哪里去

4 个答案: