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