我想开发用于公司内部使用的DAL / BLL组件,从各种应用程序和脚本访问客户和员工数据等.不过在开始构建这些东西之前,我想确保这个解决方案是“好”的.例如,BLL传递数据表而不是封装任何东西,您没有包含逻辑的隔离业务对象.它基本上只是一个愚蠢的层,简化了CRUD操作,并允许控件的数据绑定.
有谁在这个领域有经验,可以指出我的这个方法的专业和答案吗？
解决方法
– 简单的方法,一些数据映射是用datatable来完成的.
– 提供一些方便点击选择,添加,更新和删除查询.
– 可能适合非常简单的设计,几张桌子.
– 适用于非自参考ER degigns或ER,具有少量查找表和简单/少量连接
– 适合在需要简单数据存储的地方.即.复杂的OO想法应该适用于“商业对象”,这种模式会使事情变得更加困难.
缺点：
– 大型OO模式将在这种模式中奋斗
– 具有许多表,复杂关系或OO对象要求的复杂ER设计将不适合此模式.数据表不会为像LINQ这样的代码内对象查询提供很多帮助.
– 大多数查询需要用sql编写(这包括连接).是的,您可以使用查询设计器,但是这不足够.
– 这种方法有很多代码重复.因为您将在BLL类中编写大量的CRUD方法(您也需要从头开始编写).
结论：
这真的取决于你的要求.如果你的实现很小/简单,那么这可能是一个好主意.但是,以这种方式,一个小小的想法将会变得更加困难.更多的OO方法将使您更好地重构/扩展.
这种模式也比较老/陈旧.对象查询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
