数据层和DTO

这真的取决于你的架构。

在大多数情况下,您应该尝试对接口进行编码,那么您的实现实际上并不重要。如果您返回isometing,它可能是您的某个ThingEntity或您的某个ThingDTO,但是只要您的消费代码实现了接口,它就不会那么在意。

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

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

您应该首先尝试分离代码,并通过在层之间插入一些接口(如数据访问层的存储库)使其松散耦合。然后,存储库返回由接口封装的实体。这将使您的代码更易于测试,并允许您更轻松地进行模拟。一旦测试就位,就可以开始以更低的风险更改实现。

如果您开始使用接口,我建议您尽早集成一个IOC,比如温莎。如果你从一开始就这样做的话,以后会更容易。

一件事是数据集在实现互操作性方面很差。当使用非.NET客户端的类型化数据集时,即使是类型化数据集也不太兼容。参考 this link . 如果必须实现互操作性,那么就要为DTO而努力,否则就要让您的团队在一段时间内理解DTO,因为毕竟数据集并不那么糟糕。

在接口的一部分,是的,您应该公开接口。例如-如果您要返回 List<T> 你应该从达尔回来 IList<T> . 有些人只会返回 IEnumerable<T> 因为你所需要的只是列举的能力。但是当你这样做的时候 astronaut architect .

在我的申请中,我发现 ILIST & T;T & GT; 而不是 列表& T; 这样的代码会污染我的代码库:

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

所以我个人尝试在返回接口或具体对象之间保持平衡。如果你问我现在在做什么,我会告诉你我回来了 列表& T; . 我受影响不成为 宇航员建筑师 .

我总是使用DTO,从不使用数据表。但我只使用它们从BL转移到DL,反过来。我的表示层通常只知道面向服务的业务和服务层。

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

• 轻松重构
• 简单的图表制作
• 更清晰更易读的代码,尤其是在DAL的单元测试中

根据定义,DTO是一个数据传输对象,用于(等待)将数据从一个层传输到另一个层。

DTO可以跨所有层使用,我已经将它们与Web服务很好地结合使用了。