C#数据层和Dto

Question

我最近加入了一家使用类型化数据集作为“Dto”的公司。我认为他们真的很垃圾，想要把它改成更现代、更用户友好的东西。所以，我试图更新代码，使数据层更通用，即使用接口等，另一个人不知道什么是Dto，我们对如何做有一点分歧。

我不会试图动摇人们对我的想法的看法，我希望从你们这些人那里得到公正的答案，关于Dto可以存在于哪些层次。所有层；DAL、BL和表示，或者仅在这些层中的一个小子集。

另外，IList对象是否应该出现在DAL中。

谢谢。

Answer 1

这真的取决于你的架构。

在大多数情况下，你应该尝试对接口进行编码，然后你的实现是什么都无关紧要。如果您返回ISomething，它可能是您的SomethingEntity或SomethingDTO，但是您的消费代码并不关心，只要它实现接口即可。

您应该在具体的集合或数组上返回IList/ICollection/IEnumerable。

• Properties should not return arrays
• Do not expose generic lists

首先，您应该尝试分离代码，并通过在层之间插入一些接口来使其松散耦合，例如DataAccess层的存储库。然后，您的存储库返回由接口封装的实体。这将使您的代码更具可测试性，并允许您更容易地模拟。一旦您的测试就绪，您就可以开始以较低的风险更改实现。

如果您确实开始使用接口，我建议您尽早集成像Windsor这样的IoC。如果你从一开始就这样做，以后会让事情变得更容易。

Answer 2

一件事是DataSets很难实现互操作性。当涉及到从非.net客户端使用类型化数据集时，即使是类型化数据集也不是很兼容。请参阅this link。如果您必须实现互操作性，那么就努力争取DTO，否则，请尝试让您的团队在一段时间内理解DTO，因为数据集毕竟并不是那么糟糕。

在接口的一部分，是的，你应该公开接口。例如，如果您从DAL返回List<T>，则应返回IList<T>。有些人只返回IEnumerable<T>，因为您所需要的就是枚举功能。但是在这样做的时候，不要变成astronaut architect。

在我的应用程序中，我发现返回IList<T>而不是List<T>会使用如下代码污染我的代码库：

//consider personCollection as IList<Person>
(personCollection as List<Person>).ForEach(//Do Something)

因此，我个人尝试在返回接口或具体对象之间保持平衡。如果你问我现在在做什么，我会告诉你我正在返回List<T>。我受到了影响，没有成为astronaut architect。

Answer 3

我总是使用DTO，从不使用DataTable。但我只使用它们来从BL转换到DL，或者反过来。在面向服务的情况下，我的表示层通常只知道业务层和服务层。

我可以看到使用DTO而不是数据表的好处：

简单的refactoring

• easy图表production

• cleaner
• 可读性更强的代码，特别是在DAL的单元测试

中