.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
最佳答案
0
关于条件可以在参数中使用 IColleciton 之类的东西进行传递，从设计上将这个是不好的，只是为了规避UI出现 sql（甚至是 BL 出现 sql）的问题
UI变化的程度比业务变化大，如果完全采用 orm 不会得到太好的结果，如果我添加一个显示列，是不是要修改 业务层 的实体呢？
建议适当控制使用 DataTable ，体验一下 ORM
其他回答(9)
0
分层的意义就是分离职责
0
如果你完全遵循所谓的三层架构，UI层不应该出现SQL代码，所有逻辑全部封闭为方法，会疯掉的话就请别用三层了
0
我做的三层就是把SQL都封装到了数据层，包括那些where,order by,表名等都是参数传进去的....一楼说的对，还有代码重用.
0
显然不应该。UI层主要负责显示用户界面，至于想要的数据，应该在数据层或逻辑层把数据取出来。
0
我举个例子吧，如果你有多个页面都有类似的组合查询功能，你在UI层做SQL拼接，那你可能会在多个地方做多次类似的拼接工作。有一天你突然发现你需要这些组合查询进行一些改动，可能就是业务逻辑上做些变动但界面不需要动，比如你原来是默认按时间排序的，现在想按名称排序了，这时你就头大了，好几个页面都要改，工作量一下子增加不少，而且还可能遗漏，导致有的页面改过来了，有的页面还是老样子。
0
UI不应该出现SQL。如果排序复杂可以考虑客户端排序。例如像Teleric等第三方控件的Grid都自带了排序功能，不需要程序员另外编码，就可以自动按列排序了。不用第三方控件的话可以考虑使用List的Sort方法。
0
要理解三层的实际含义，严格的三层的UI层是绝对不可以出现SQL，否则就不是三层架构了！三层架构就是为了分离职责，如果你觉得在数据访问层需要些很多SQL，可以考虑一下重构数据访问层，可以共享的地方要共享，或做一个通用的东西等！
0
就问题而言 这个是肯定的。
0
鱼和熊掌难以兼得.
