|
锁定老帖子 主题：讨论:在浏览器上生成SQL语句可行吗?
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-05-31
liujunsong 写道 robbin 写道 一个最直接的问题就是你无法重用业务逻辑了。任何页面操作都需要你从头开始写SQL语句，一旦表结构发生微小的变动，你的整个web应用全部需要重写一遍。
关于业务逻辑重用的问题,我是这么看的. 首先,在一个应用中,能够重用的业务逻辑,在整个系统的所有业务逻辑中,其实比例不大,不会超过10%.对于这10%,可以考虑把逻辑放到后台来实现,以实现重用;其余90%,就直接在前台用SQL来搞定. 第二,在现在的设计中,为了业务逻辑的重用,经常会在各个类之间调用来调用去,一个数据转换来转换去,最后在看程序的时候,很难搞清楚这个业务过程到底访问了那些表,进行了那些实际操作,这种复杂性是否值得,我觉得很多时候需要具体分析才能确定. 对于表结构变化引起的SQL变化,以及页面的重写,我认为这在目前的情况下是无法避免的,无论SQL在那里生成,都是需要改写,并且调试才行的. 但对于在界面上直接写SQL的,可以只修改一个页面就直接看到修改后的效果,而采用SSH及类似方式,数据表修改以后需要修改一大堆东西而能真实看到实际修改修改.效率并不高. 只能说你没有做过具有稍微复杂度的web系统，所以站着说话不腰疼。so，just do it |
| 返回顶楼 | |
|
发表时间：2009-05-31
robbin,我有个朋友在YAHOO做的就是这个东东，搭建成了一个平台
当然不是简单在页面级写SQL，但是核心也是在页面上生成了SQL，后端实际上就是一个数据库而已。 |
| 返回顶楼 | |
|
发表时间：2009-05-31
至于安全性的问题就要看使用环境和具体应用场景了
公网的当然不能这么玩，限定在特定的场景里还是可以的。 |
| 返回顶楼 | |
|
发表时间：2009-05-31
kunee 写道 至于安全性的问题就要看使用环境和具体应用场景了
公网的当然不能这么玩，限定在特定的场景里还是可以的。 既然你也说公网，局限性就很大。 j2ee 如果做公网，那不是有很大浪费哦。。 如果考虑做大型的话，你想想怎么维护吧。。如果有个改动，你看看要改多少东西。。 做小型不错的方法 |
| 返回顶楼 | |
|
发表时间：2009-05-31
liujunsong 写道 flyspider 写道 两个问题:
1.UI与业务逻辑的耦合度增大 2.严重的安全隐患 重申一下我的思路,UI现在和业务逻辑不仅仅是耦合了,而是直接采用Javascript来编写业务逻辑,业务逻辑大部分在javascript里面调用实现,少部分在后台java实现,通过DWR等方式来调用. 具体到安全隐患,需要细化说明,究竟可能存在那种安全隐患,然后再来讨论究竟有没有解决方案. 1.你多大规模的项目?如何用js构架?如何协同?如何用js来实现你的大部分业务逻辑?如何测试? 2.js实现权限控制? 3.如何控制客户端可以执行哪些SQL?就是数据库专家这问题也够喝几壶的 |
| 返回顶楼 | |
|
发表时间：2009-05-31
既然如此要浏览器干什么呢？
Powerbuilder，VB最好啊， 很多应用真的没有必要搞上浏览器。 |
| 返回顶楼 | |
|
发表时间：2009-05-31
kunee 写道 robbin,我有个朋友在YAHOO做的就是这个东东，搭建成了一个平台
当然不是简单在页面级写SQL，但是核心也是在页面上生成了SQL，后端实际上就是一个数据库而已。 YAHOO也许是在特定约束条件下为解决特定场景的问题才这么做的 |
| 返回顶楼 | |
|
发表时间：2009-05-31
pl-sql?
oracle网页版?很好用. 可以试试 |
| 返回顶楼 | |
|
发表时间：2009-05-31
kunee 写道 至于安全性的问题就要看使用环境和具体应用场景了
公网的当然不能这么玩，限定在特定的场景里还是可以的。 在哪里都不能这么玩，除非是你家里几台机器互相玩。 框架怎么设计是其次的，你可以想到很花哨很精致的实现方式。 但只要是在客户端拼装SQL就有问题，管你是js、flex、silverlight什么的，哪怕是拼装一个where子句都有漏洞。 用户直接拦截、重新拼装SQL，你的框架就废了。就算跑在SSL上也不能保证安全。 退一步讲，就算你能完全保证SQL不被篡改，但人家看到你的SQL、了解你的数据库结构，那就是漏洞了。 |
| 返回顶楼 | |
|
发表时间：2009-05-31
最后修改：2009-05-31
引用 首先,在一个应用中,能够重用的业务逻辑,在整个系统的所有业务逻辑中,其实比例不大,不会超过10%.
这个在复杂的erp系统中是不成立的。起码我们现在的系统，可重用的业务逻辑远远大于10%。而且我们还只是小公司而已。 引用 那么数据库就可以直接暴露在用户前端,只要加上一定的用户界面,完全可以将现在后台做的工作移植到前台来做.
既然是用SQL直接来做，为什么不用stored procedure算了？还搞个javascript调用，不是多此一举。而且在stored procedure里无论想使用多复杂的sql都没有问题。 引用 最后在看程序的时候,很难搞清楚这个业务过程到底访问了那些表,进行了那些实际操作
很多复杂的业务过程，从对象上面去分析会更直观。我觉得应该从这个业务过程使用了对哪些business object进行了什么操作方面去理解业务。 引用 对于表结构变化引起的SQL变化,以及页面的重写,我认为这在目前的情况下是无法避免的,无论SQL在那里生成,都是需要改写,并且调试才行的.
调试java比调试javascript要容易得多。 引用 但对于在界面上直接写SQL的,可以只修改一个页面就直接看到修改后的效果,而采用SSH及类似方式,数据表修改以后需要修改一大堆东西而能真实看到实际修改修改.效率并不高.
采用orm是有overhead，在系统简单的情况下可能这种overhead所占的权重很大。但随着系统复杂性增加，overhead所占的比重就越来越小了。这就是为什么我写一个留言本程序可以不考虑任何分层，直接用jsp+jdbc高定，但在实际项目中却很少人这么写。 把业务逻辑放在后台，可以通过继承，重载，拦截器，依赖注入等方法最大限度的复用程序。比如说对于n个80%相似的业务逻辑，就可以提供一个父类，完成公共的操作。n个子类只需要重载少数方法就可以了。你拿到前台来做，javascript无论是在功能还是执行效率方面，都还远远逊色。 BTW，直接用sql，如果你业务对象的某一个字段需要时binary data，比如说blob，处理起来远远比有一个orm帮你要复杂。 再BTW，我极为反对你的观点，但我不投你新手贴。对于讨论性质的帖子，我也很反感动不动就投新手。 |
| 返回顶楼 | |
