首页 新闻 搜索 专区 学院

.net三层架构UI层是否不应该出现SQL代码.

0
悬赏园豆:20 [已解决问题] 解决于 2008-12-19 16:39

经常看到一些大虾谈论三层架构,说UI层不能出现SQL代码,有的甚至说业务逻辑层都不能出现SQL代码。。
我不理解他们是怎么做的,避开ORM及LINQ等工具,用户的查询条件、排序是动态多变的,如果不在UI传递SQL。那不是要针对
用户所能涉及到的查询及排序在业务逻辑层里都要写个方法?  如果是那样的话我会疯掉的。
我自己做过一些三层的系统。复杂多条件的查询都是直接在UI层拼接Sql然后传到业务层的。
当然拼接Sql如果检查或过滤不当可能导致存在Sql存入的安全隐患。

希望听听大家的意见及看法, 或解决方案。

这个是我用三层开发的第一个网站。 谢谢指点: http://www.08px.com/

问题补充: 大家看一下我在csdn发的一个贴子,也是针对该问题的. 这里回复不怎么好贴代码了 http://topic.csdn.net/u/20081211/17/a3c04b56-c6ec-4f80-991e-d8a3d4bf89b7.html?seed=1532120626#replyachor
ruson的主页 ruson | 初学一级 | 园豆:150
提问于:2008-12-11 20:20
< >
分享
最佳答案
0

关于条件可以在参数中使用 IColleciton 之类的东西进行传递,从设计上将这个是不好的,只是为了规避UI出现 sql(甚至是 BL 出现 sql)的问题

UI变化的程度比业务变化大,如果完全采用 orm 不会得到太好的结果,如果我添加一个显示列,是不是要修改 业务层 的实体呢?

建议适当控制使用 DataTable ,体验一下 ORM

孤剑 | 菜鸟二级 |园豆:328 | 2008-12-11 23:31
其他回答(9)
0

分层的意义就是分离职责

李永京 | 园豆:3114 (老鸟四级) | 2008-12-11 20:30
0

如果你完全遵循所谓的三层架构,UI层不应该出现SQL代码,所有逻辑全部封闭为方法,会疯掉的话就请别用三层了

Gray Zhang | 园豆:17610 (专家六级) | 2008-12-11 20:43
0

我做的三层就是把SQL都封装到了数据层,包括那些where,order by,表名等都是参数传进去的....一楼说的对,还有代码重用.

Astar | 园豆:40805 (高人七级) | 2008-12-11 21:21
0

显然不应该。UI层主要负责显示用户界面,至于想要的数据,应该在数据层或逻辑层把数据取出来。

ci bonfire | 园豆:235 (菜鸟二级) | 2008-12-11 22:18
0

我举个例子吧,如果你有多个页面都有类似的组合查询功能,你在UI层做SQL拼接,那你可能会在多个地方做多次类似的拼接工作。有一天你突然发现你需要这些组合查询进行一些改动,可能就是业务逻辑上做些变动但界面不需要动,比如你原来是默认按时间排序的,现在想按名称排序了,这时你就头大了,好几个页面都要改,工作量一下子增加不少,而且还可能遗漏,导致有的页面改过来了,有的页面还是老样子。

eaglet | 园豆:17119 (专家六级) | 2008-12-12 07:38
0

UI不应该出现SQL。如果排序复杂可以考虑客户端排序。例如像Teleric等第三方控件的Grid都自带了排序功能,不需要程序员另外编码,就可以自动按列排序了。不用第三方控件的话可以考虑使用List的Sort方法。

1-2-3 | 园豆:200 (初学一级) | 2008-12-12 08:42
0

要理解三层的实际含义,严格的三层的UI层是绝对不可以出现SQL,否则就不是三层架构了!三层架构就是为了分离职责,如果你觉得在数据访问层需要些很多SQL,可以考虑一下重构数据访问层,可以共享的地方要共享,或做一个通用的东西等!

GUO Xingwang | 园豆:3885 (老鸟四级) | 2008-12-12 09:15
0

就问题而言 这个是肯定的。

金鱼 | 园豆:1090 (小虾三级) | 2008-12-12 10:58
0

鱼和熊掌难以兼得.

有所为,有所不为 | 园豆:1200 (小虾三级) | 2008-12-17 10:33
清除回答草稿
   您需要登录以后才能回答,未注册用户请先注册