.NET中的DAL和BLL

Question

这是微软为ASP.NET (2.0)应用开发的DAL/BLL design suggestion。我知道一些替代方案，我已经在SO上阅读了相关问题。然而，我想知道现在这个提议的解决方案是否值得实施，你知道有什么具体的缺点吗？

我想开发DAL/BLL组件供公司内部使用，从各种应用程序和脚本访问客户和员工数据等。然而，在我开始构建这些东西之前，我想确保这个解决方案是“好的”。例如，BLL传递数据表而不是封装任何内容，您没有包含逻辑的孤立业务对象。它基本上只是一个哑层，它稍微简化了CRUD操作，并允许为控件绑定数据。

在这个领域有经验的人能给我指出这种方法的优缺点吗？

Answer 1

的优点：

• 是一种简单的方法，一些数据映射是通过数据表为您完成的。
• 为触发选择、添加、更新和删除查询提供了一些便利。
• 可能适用于只有少量表的非常简单的设计。
• 适用于具有较少查找表和简单/较少连接的非自引用ER数字或ER。
• 适用于需要简单数据存储的地方。即。当复杂的OO思想应该应用于“业务对象”时，这种模式会使事情变得更加困难。

的缺点：

• 大型OO模型将在此模式中挣扎
• 具有许多表、复杂关系或OO对象需求的复杂ER设计将不适合此模式。数据表并不像LINQ那样为代码内对象查询提供太多帮助。
• 大多数查询都需要在SQL中手工编写(包括连接)。是的，您可以使用查询设计器，但这不会有太大帮助。
• 在这种方法中有很多代码重复。正如在中一样，您将在BLL类中编写大量的CRUD方法(您还需要从头开始编写)。

结论：这真的取决于你的需求。如果您的实现很小/简单，那么这可能是一个好主意。但是，使用这种方法很难在一个小想法上成长。一种更面向对象的方法将为以后的重构/扩展设置得更好。此模式也较旧/过时。对象查询IQueryable/LINQ更加流行，不久将成为更广泛的标准。我建议你跳上这辆马车。从长远来看，这对你的个人发展也是更好的。:D

一些链接：

你的范围更大了，这将是一个方便的模式的一个很好的开始- http://www.asp.net/learn/mvc-videos/video-350.aspx

• 尝试aspnet MVC -http://www.asp.net/learn/mvc-videos/video-350.aspx

Answer 2

我强烈建议不要使用DATATABLES。查看一个域驱动的设计实现，您的整个框架将使用您可以传递到List<>或Queryable<>中的常规对象。DataTables是垃圾，甚至不应该再包含在.NET中。

我还建议使用依赖注入/控制反转框架，如Microsoft Unity或StructureMap来创建松散耦合的代码。