类的转换方法在哪里去

的DataRow - >对象转换
视图模型< - >模式转换

我的问题是应该在哪里居住功能？

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

来源

2010-08-11 Alan Jackson

：没有单一的答案。如何最好地进行转换将取决于被转换的事物的类型，其生命周期以及一系列其他因素。 – kyoryu 2010-08-12 01:16:57

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

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

来源

2010-08-11 17:00:30

可能......你也可以使ViewModel本身充当桥接器或适配器的论点，尤其是因为（正如我在我的回答中提到的那样）ViewModel可能仍然有一个对Employee的引用。如果情况并非如此，我完全同意SRP建议选项3. – kyoryu 2010-08-11 17:02:55

我同意....... – 2010-08-11 17:05:33

@ kyoryu - 请参阅我的编辑。在我读到你的答案后，我开始思考它，并且这个方法把我扔掉了，这属于ViewModel的构造函数。 – 2010-08-11 17:14:48

我实际上可能会说选项2.由于具有ViewModel的整个观点是在底层模型和视图的需求之间提供逻辑“翻译层”，它似乎是非常ViewModel。（在我看来），因为它打破了Model和ViewModel之间的分离（考虑 - 理论上有多个ViewModel可能需要查看员工数据，而且他们可能都不一样）。

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

来源

2010-08-11 17:01:22 kyoryu

+1帮助我想到构造函数。 – 2010-08-11 17:20:53

您可能需要考虑诸如AutoMapper之类的内容。虽然它最初是为DTO和ViewModel对象之间的映射而开发的，但它非常强大，并且可以移除所有映射代码，而无需额外增加许多类。

来源

2010-08-11 17:17:58 CubanX

这可能是这些“个人偏好”情况之一。您的每个选项都是在。NET库，所以我们可以猜测有没有从微软的角度旗帜鲜明的最佳实践：

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

每个澄清：

来源

2010-08-11 19:12:55 mikemanne

类的转换方法在哪里去

回答

相关问题