Microsoft 为 ASP.NET (2.0) 应用提供了这个 DAL/BLL design suggestion。我知道一些替代方案，并且我已经在 SO 上阅读了相关问题。但是我想知道这个提议的解决方案现在是否值得实施，您是否知道具体的缺点？
我想开发 DAL/BLL 组件供公司内部使用，以从各种应用程序和脚本访问客户和员工数据等。但是，在我开始构建这些东西之前，我想确保这个解决方案是“好的”。例如，BLL 传递数据表而不是封装任何东西，您没有包含逻辑的隔离业务对象。它基本上只是一个愚蠢的层，可以稍微简化 CRUD 操作并允许控件的数据绑定。
有这方面经验的人可以指出这种方法的优缺点吗？
【问题讨论】：
标签： c# asp.net datatable data-access-layer bll
优点：
-简单的方法和一些数据映射是用数据表为你完成的。
- 为触发 Select、Add、Update 和 Delete 查询提供了一些便利。
- 可能适用于很少桌子的非常简单的设计。
- 适用于非自引用 ER 设计或具有少量查找表和简单/少量连接的 ER
- 适用于需要简单数据存储的地方。 IE。复杂的 OO 思想应该应用于“业务对象”，这种模式会使事情变得更加困难。
缺点：
- 大型 OO 模型在这种模式下会遇到困难
- 具有许多表、复杂关系或 OO 对象要求的复杂 ER 设计不适合这种模式。数据表没有为像 LINQ 这样的代码内对象查询提供太多帮助。
- 大多数查询需要用 SQL 手工编写（包括连接）。是的，您可以使用查询设计器，但这并没有多大帮助。
- 这种方法有很多代码重复。因为您将在 BLL 类中编写大量 CRUD 方法（您也需要从头开始编写）。
结论： 这真的取决于你的要求。如果您的实现很小/简单，那么这可能是一个好主意。但是这种方法很难在一个小想法上成长。更多的面向对象方法将为您以后的重构/扩展做好准备。 这种模式也较旧/过时。对象查询 IQueryable/LINQ 更流行，不久将成为更广泛的标准。我建议你跳上这辆马车。从长远来看，这对您的个人发展也会更好。 :D
一些链接：
【讨论】：
我完全建议不要使用数据表。查看一个领域驱动的设计实现，您的整个框架将与您可以传递给 List 或 Queryable 的常规对象一起工作。数据表是垃圾，甚至不应该再包含在 .NET 中了。
我还建议研究使用依赖注入/控制反转框架（例如 Microsoft Unity 或 StructureMap）来创建松散耦合的代码。
【讨论】：