我正在尝试提供何时使用数据传输对象以及何时使用DataTables的方法。
作为我在系统中遇到的问题的一个例子...
我们有6个不同的业务实体程序集代表相同的东西但具有不同的属性。它们是由几个开发人员在几年内就不同问题创建的。
例如，多年来使用“自行车”类的不同应用涉及自行车的不同特性。因此，他们调用了不同的数据方法，这些方法只检索并填充了他们所关注的属性。
数据服务1填充
数据服务2填充
每个都使用不同的业务实体。显然这很荒谬，你无法为每种可能的属性组合创建一个新类。
我的直觉告诉我，如果这是一个问题，那么我们应该使用ORM。
但暂时我想说。
如果要从表中填充或返回整行，请使用与数据库匹配的DTO / Business Entity。
如果要返回一组随机属性，请使用数据表。
有人可以提供一些指导吗？
由于
答案 0 :(得分：5)
我会保持简单并始终返回一个DataSet - 简而言之，使用DataSet作为通用DTO。它是灵活的，它是类型安全的，它是可用的。除非你进入一些非常毛茸茸的嵌套对象模型，否则DTO不会为你付出任何代价。
答案 1 :(得分：5)
这将根据我们所讨论的系统的大小而有所不同。如果这些是真正独立的系统，那么它们可以使用不同的方式来查看相同的概念。这称为有界上下文：http://dddcommunity.org/discussion/messageboardarchive/BoundedContext.html
如果是这种情况，那么您可能遇到的问题是您通过数据库在不同的有界上下文之间进行通信，而不是通常在API级别的显式边界。
另请注意，管理或返回信息子集并不一定意味着使用单独的类。您可以让共享类实现不同的接口，因此调用代码能够处理信息的子集。
答案 2 :(得分：2)
将实体与数据库分离没有任何问题。您可以使用Entity Framework轻松完成此操作。您可以将多个实体映射到同一个表或一组表，每个表都有不同的属性集。
另一方面，现在也没有理由不对常用的“自行车”定义进行标准化。如果数据服务1只想更新品牌和颜色，则可以进行UpdateBrandAndColor操作。它不需要传递整个实体，只需要传递它的ID，品牌和颜色。与#gears和轮胎尺寸相同。
但是应该只有一个从GetBicycle操作返回的Bicycle实体类型。