|
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-10-07
个人认为论坛这种小型应用，一开始先泛型DAO+Action实现基本功能，搭建好整个基础架构。再来根据实际需要是否进一步的分出Service这一层。
另外，看到LZ第一句“先从数据库设计开始”让我很震惊。 个人会比较认同将数据库作为数据仓储用，不使用其约束、存储过程、关系等特性，虽然用的还是关系数据库。 XD |
| 返回顶楼 | |
|
发表时间：2011-10-07
建议LZ先把需求描述清楚吧。
|
| 返回顶楼 | |
|
发表时间：2011-10-07
容易被注入
|
| 返回顶楼 | |
|
发表时间：2011-10-07
stackoverflow 写道 一个BaseDao 一个BaseDaoImpl 做实现 其他Dao接口实现BaseDao 实现继承BaseDaoImpl
这样你的Dao才干净。。 
|
| 返回顶楼 | |
|
发表时间：2011-10-08
laiweiweihi 写道 个人认为论坛这种小型应用，一开始先泛型DAO+Action实现基本功能，搭建好整个基础架构。再来根据实际需要是否进一步的分出Service这一层。
另外，看到LZ第一句“先从数据库设计开始”让我很震惊。 个人会比较认同将数据库作为数据仓储用，不使用其约束、存储过程、关系等特性，虽然用的还是关系数据库。 XD 我们项目组有的项目是在数据库之间不建立关联关系,关联之间一般保存id,如果是多的话,就用List来保存id关系,也没什么问题,但是我个人认为这样不能保证数据的完整性.尤其表现在删除的时候. |
| 返回顶楼 | |
|
发表时间：2011-10-08
先说下MAP的缺点，sql/hql优化对查询效率来说非常重要，因此where后各条件位置决定着查询速度；
用map的key遍历的话，where后的语句就没有先后顺序而言； 有时候符合查询，你这种情况很难满足；orderby 不建议这么写，因为一般情况，可能会orderby跟多个排序方式；建议用1.5新特性 .. 的方式； |
| 返回顶楼 | |
|
发表时间：2011-10-08
个人觉得可以在service和dao以及action之间使用threadlocal来进行参数的传递，进而来减少耦合
|
| 返回顶楼 | |
|
发表时间：2011-10-08
曾经使用过ibatis,中间对于sql的构造有很大一部分是用这样的方式Map来传送的。不过就像Liu.anxin所说的那样，要好好注意下注入的问题了。
|
| 返回顶楼 | |
|
发表时间：2011-10-08
最后修改：2011-10-08
简单拼接, 用 可变参数.
单对象, 用 findByExample. 复杂对象且有级联, 用 DetachedCriteria. 复杂对象无级联关系, 用 Native SQL. 保证一点: 从页面过来的参数一定要使用 ? 占位符 |
| 返回顶楼 | |
