我一直在查看 3 层设计网络上的示例，我注意到大多数示例返回数据集或数据表。令我困惑的是，如果您宁愿返回一个通用类型列表，以便您可以利用列表所基于的类型中的属性或方法，该怎么办？例如，使用根据数据以特定方式连接各种字段的 Name 属性，如果 List 绑定到表单上的控件，则 Name 属性可以用作数据字段。如果您想在使用数据集或表时完成相同的事情，则必须从数据库中返回数据以达到相同的目的（我尽量不使用数据集或数据表，所以我可能对这个语句非常错误. :) )
真正让我困惑的部分是关于重用代码，对我来说，重用代码的唯一方法似乎是将数据检索到数据集或数据表中，然后遍历数据并将其添加到列表中，这通常是3 层的最佳实践，或者有没有办法在没有数据集和数据表的情况下做到这一点。
下面链接中的示例实质上演示了使用数据集或表，然后将其添加到对象中，但我不得不问这是否是最佳实践？
http://www.codeproject.com/Articles/36847/Three-Layer-Architecture-in-C-NET
谢谢
使用DataTables 是一种特定的网络主义。其背后的原因是它们包含有关数据结构的元数据，它可以让DataGrid（和其他此类组件）自动显示数据，而无需使用反射等。我的猜测是，这是对 RAD 的 MS Access 方法的继承，其目的是使“业务人员”能够通过直接从 SQL 模式生成用户界面来创建应用程序，基本上与分层设计相反。这种传承似乎已经渗入了主脑。
只要您愿意放弃 RAD 功能，使用“普通”数据结构并没有错，而且最近的趋势似乎也是摆脱这种权衡。（例如，使用 Web 窗体的强类型数据控件和 MVC 的模型绑定功能。）
此外，更一般地说，MVC 建立之前的代码项目文章并不是关于一般软件架构的真正智慧来源。
您应该携带什么数据完全取决于您的需求。
如果您从数据库中检索数据并将其绑定到数据网格，数据集可能会为您提供完美的解决方案。如果您想要一些其他方法来跟踪数据自己的更新状态，您应该查看实体框架。如果您检索数据并通过 Web 服务发送数据以进行跨平台或跨域处理，您需要将数据加载到您自己的其他一些可序列化类中。
看看下面的文章。它有点老了，针对的是 EF4，但它很好地总结了不同策略的优缺点。（本系列共三篇，建议大家阅读）
我认为您找到的示例使用了数据表和数据集，因为这是展示 3 层设计的一种简单方法。现在实体框架已经在很大程度上取代了示例中提到的“数据访问层”。
在实体框架之前，当我编写数据访问层时，我会返回一个从数据库构建的通用列表。要运行更新、删除或插入，我会将对象作为参数传递给方法，然后使用对象的属性作为 sql 语句中的值。出于您提到的原因，我更喜欢这样做，但也因为它允许我彼此独立地更改对象定义或数据库模式（甚至一起使用不同的数据库）。