C# 数据层和 Dto
我最近加入了一家使用类型化数据集作为“Dto”的公司。我认为他们真的很垃圾，想把它改成更现代、更用户友好的东西。因此，我正在尝试更新代码，以便数据层更加通用，即使用接口等，其他人不知道 Dto 是什么，并且我们对于应该如何完成它有一些分歧。
在不试图影响人们接受我的思维方式的情况下，我希望从你们那里得到关于 Dto 可以存在于哪些层的公正答案。 DAL、BL 和表示或仅在这些层中的一个小子集。
另外，IList 对象是否应该出现在 DAL 中。
谢谢。
I have recently joined a company that using typed datasets as their 'Dto'. I think they are really rubbish and want to change it to something a little more modern and user friendly. So, I am trying to update the code so that the data layer is more generic, i.e. using interfaces etc, the other guy does not know what a Dto is and we are having a slight disagreement about how it should be done.
Without trying to sway people to my way of thinking, I would like to get impartial answers from you people as to what layers the Dto can be present in. All layers; DAL, BL and Presentation or a small sub set within these layers only.
Also, whether IList objects should or should not be present in the DAL.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这实际上取决于您的架构。
大多数情况下，您应该尝试对接口进行编码，然后您的实现是什么并不重要。如果您返回 ISomething，它可能是您的 SomethingEntity 或 SomethingDTO，但您的消费代码只要实现该接口就不会关心。
您应该通过具体集合或数组返回 IList/ICollection/IEnumerable。
您首先应该尝试做的是通过在层之间插入一些接口（例如数据访问层的存储库）来分离代码并使其松散耦合。然后，您的存储库返回由接口封装的实体。这将使您的代码更易于测试，并允许您更轻松地进行模拟。一旦测试到位，您就可以开始以较小的风险更改实现。
如果您确实开始使用接口，我建议您尽早集成 Windsor 等 IoC。如果你从一开始就这样做，以后的事情就会变得更容易。
It really depends on your architecture.
For the most point you should try to code to interfaces then it doesn't really matter what your implementation is. If you return ISomething it could be your SomethingEntity or your SomethingDTO but your consuming code doesn't care less as long as it implements the interface.
You should be returning an IList/ICollection/IEnumerable over a concrete collection or array.
What you should try to do first is separate your code and make it loosely coupled by inserting some interfaces between your layers such as a repository for your DataAccess layer. Your repository then returns your entities encapsulated by an interface. This will make your code more testable and allow you to mock more easily. Once you have your tests in place you can then start to change the implementations with less risk.
If you do start to use interfaces I would suggest integrating an IoC such as Windsor sooner rather than later. If you do it from the get go it will make things easier later on.
一件事是数据集很难实现互操作性。当从非 .net 客户端使用类型化数据集时，即使类型化数据集也不太兼容。请参阅此链接。如果您必须实现互操作性，那么就努力争取 DTO，否则尝试让您的团队在一段时间内理解 DTO，因为数据集毕竟不是那么糟糕。
在接口的一部分上，是的，您应该公开接口。例如 - 如果您从 DAL 返回
List，则应返回IList。有些人只返回IEnumerable因为您所需要的只是枚举能力。但在这样做的同时，不要成为宇航员建筑师。在我的应用程序中，我发现返回
IList而不是List会用这样的代码污染我的代码库：所以我个人尝试保持平衡返回接口或具体对象之间。如果你问我现在在做什么，那么我会告诉你我正在返回
List。我受到影响，没有成为宇航员建筑师。One thing is DataSets are poor to achieve interoperability. Even typed datasets are also not so compatible when it comes to consuming typed datasets from a non .net client. Refer this link. If you have to achieve interoperability then fight hard for DTOs otherwise try to make your team understand DTOs over a period of time because datasets are not so bad after all.
On part of interfaces, yes you should be exposing interfaces. For example - If you are returning
List<T>from DAL, instead you should returnIList<T>. Some people go to extent of returning onlyIEnumerable<T>because all you need is capability to enumerate. But then while doing it don't become astronaut architect.In my applications I have figured out that returning
IList<T>instead ofList<T>pollutes my code base with codes like this:So I personally try to maintain a balance between returning interface or concrete object. If you ask me what I am doing right now, then I will tell you I am returning
List<T>. I am influenced to not to become astronaut architect.我总是使用 DTO，从不使用 DataTable。但我只用它们从 BL 转移到 DL，反之亦然。在面向服务的情况下，我的表示层通常只知道业务层和服务层。
我可以看到使用 DTO 而不是数据表的好处：
I always use DTOs, never DataTable. But I only use them to transfer from BL to DL and the other way around. My presentation layers are often only aware of the business and service layers in case of service oriented.
The benefits I can see to use DTOs rather than datatables:
根据定义，DTO 是一个数据传输对象，用于（等待）将数据从一层传输到另一层。
DTO 可以跨所有层使用，我在 Web 服务中很好地使用了它们。
By definition a DTO is a data transfer object, used to (wait for it) transfer data from one layer to another.
DTOs can be used across all layers and I have used them well with web services.