.NET中的DAL和BLL

有此DAL/BLL设计建议为ASP.NET(2.0)应用由微软.我知道一些替代方案,我在这里已经阅读了相关问题.但是我想知道这个提议的解决方案现在是否值得实施,你知道的是否有一个特定的缺点？

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

在这个领域有经验的人能否指出我对这种方法的赞成和反对意见？

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

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

优点:
- 简单的方法和一些数据映射是通过数据表完成的.
- 为选择,添加,更新和删除查询提供了一些便利.
- 可能适合非常简单的设计,只有很少的桌子.
- 适用于非自引用ER分频或具有少量查找表和简单/少数连接的ER
- 适用于需要简单数据存储的情况.即.复杂的OO想法应该应用于"业务对象",这种模式会使事情变得更加困难.

缺点:
- 大型OO模型将在这种模式中挣扎
- 具有许多表,复杂关系或OO对象要求的复杂ER设计将不适合这种模式.数据表不像LINQ那样为代码内对象查询提供很多帮助.
- 大多数查询需要在SQL中手动编写(这包括连接).是的,你可以使用查询设计器,但这没有多大帮助.
- 这种方法有很多代码重复.就像你在BLL类中编写了许多CRUD方法(你还需要从头开始编写).

结论: 这实际上取决于您的要求.如果你的实现很小/很简单,那么这可能是一个好主意.但是这种方法很难在一个小想法上成长.更多的面向对象方法将为您以后的重构/扩展提供更好的帮助.这种模式也陈旧/陈旧.对象查询IQueryable/LINQ更受欢迎,很快就会成为更广泛的标准.我建议你跳上这辆马车.从长远来看,这对你的个人发展会更好.:d

一些链接:

尝试aspnet MVC - http://www.asp.net/learn/mvc-videos/video-360.aspx?redir=true

http://www.asp.net/learn/mvc-videos/video-361.aspx?redir=true

http://www.asp.net/learn/mvc-videos/video-395.aspx

如果您的范围更大,这将是一个方便的模式的良好开端 - http://www.asp.net/learn/mvc-videos/video-350.aspx