（菜鸟问题）关于业务逻辑和数据访问分层的问题？

[sense]

我有个增加计划的业务，里面涉及10几个SQL语句（可能还更多），这样如果把数据访问单独放一层不得麻烦死了？

请问大家如何处理？

我以前做都是业务逻辑和数据访问都放在一起，听大虾们说最好分开，可我觉得分开好麻烦啊，程序量倍增，很多时候那些SQL语句很简单（SELECT COUNT(*) FROM TABLE）

另外大家推荐一下，用ibatis还是用spring jdbctemplate合适？（因为我对SQL比较熟悉，Hibernate就算了）

[sense]

[Quote=引用 5 楼 chabale 的回复:]

虽然程序量比较大，但便于代码的维护，如果你的业务逻辑发生改变的话，你就需要多处更改你的代码，如果你将数据层和业务层分开的话，你只要修改一处就ok了。。。。
如果嫌麻烦可以使用框架啊
hibernate 增删改查对应的方法 save，delete，update，query
[/Quote]

可是我一个save就涉及10几个SQL呢？？

[a3737500]

[Quote=引用楼主 sense 的回复:]
我有个增加计划的业务，里面涉及10几个SQL语句（可能还更多），这样如果把数据访问单独放一层不得麻烦死了？

请问大家如何处理？

我以前做都是业务逻辑和数据访问都放在一起，听大虾们说最好分开，可我觉得分开好麻烦啊，程序量倍增，很多时候那些SQL语句很简单（SELECT COUNT(*) FROM TABLE）

另外大家推荐一下，用ibatis还是用spring jdbctempla……
[/Quote]MVC 框架吧ibatis，但楼主应该学学hibernate的

[kouyiSC]

[Quote=引用 6 楼 sense 的回复:]
引用 5 楼 chabale 的回复:

虽然程序量比较大，但便于代码的维护，如果你的业务逻辑发生改变的话，你就需要多处更改你的代码，如果你将数据层和业务层分开的话，你只要修改一处就ok了。。。。
如果嫌麻烦可以使用框架啊
hibernate 增删改查对应的方法 save，delete，update，query


可是我一个save就涉及10几个SQL呢？？
[/Quote]
如果你10几个SQL的业务需要在同一个事务中的话，，可以写在一个dao里面。。没有人规定一个Dao只能执行一个Save的SQL。。

[鹏89]

[Quote=引用 1 楼 kouyisc 的回复:]

引用
ibatis吧。。。比较轻量级。也简单。。适合你这种SQL比较熟悉的人。。。正好你SQL语句也多。。。

我的建议还是分层。。。四层你闲麻烦 可以写三层。。如果仅仅是执行一些SQL而业务逻辑很少，并且你闲麻烦。。也可以用两层【省去业务逻辑层】来实现计划任务。。将少量业务逻辑直接放在控制层融掉。。留一个数据层来执行与IBatis交互。。。
[/Quote]同意

[sense]

咋就这么没人气呢。。。

[qybao]

[Quote=引用楼主 sense 的回复:]
我有个增加计划的业务，里面涉及10几个SQL语句（可能还更多），这样如果把数据访问单独放一层不得麻烦死了？

请问大家如何处理？

我以前做都是业务逻辑和数据访问都放在一起，听大虾们说最好分开，可我觉得分开好麻烦啊，程序量倍增，很多时候那些SQL语句很简单（SELECT COUNT(*) FROM TABLE）

另外大家推荐一下，用ibatis还是用spring jdbctempla……
[/Quote]
怎么个麻烦啊，数据通过DAO取出来，然后再处理
就是把数据添加/检索/更新/删除放到DAO，业务层通过DAO获取数据，然后再进行相关的业务处理，和你直接写一样，但是这样层次分明，可以单独使用DAO层，这样方便其他业务也能使用

[man_zhang]

照你原来的写，虽然有十个sql,你可以在一个方法实现。直接写个for循环，循环执行那个保存方法就好了。

[蜡笔小瑤]

[Quote]
[Quote]
[Quote]
[Quote]
[Quote]
[Quote]
[Quote]
[Quote]
最近刚刚使用JdbcTemplate.
[/Quote]
[/Quote]
[/Quote]
[/Quote]
[/Quote]
[/Quote]
[/Quote]
[/Quote]

[sense]

[Quote=引用 16 楼 man_zhang 的回复:]

照你原来的写，虽然有十个sql,你可以在一个方法实现。直接写个for循环，循环执行那个保存方法就好了。
[/Quote]

我的意思是说：一个save函数（一个事务）里面包含10几个SQL，我如果用ibatis的话是不是要在XML写10几个SQL？然后最重要的是不是要写10几个接口函数？最后把这10几个接口函数（实现了得）装配到一个save函数（一个事务）里头？

[wnf2009]

其实dao你可以写个通用的，其他就是写service多一点

ublic interface BaseDAO<T, K extends Serializable> extends DAO {
	/**
	 * 加载实体
	 */
	public T loadEntity(Class<T> clasz, K id) throws Exception;

	/**
	 * 加载实体
	 */
	public T getEntity(Class<T> clasz, K id) throws Exception;

	/**
	 * 删除实体
	 */
	

[我嘞个去]

[sense]

[Quote=引用 10 楼 gavin_ts 的回复:]

[/Quote]
楼上的就不要笑话我了，我才开始学习JAVA....

[sense]

[Quote=引用 8 楼 kouyisc 的回复:]

引用 6 楼 sense 的回复:
引用 5 楼 chabale 的回复:

虽然程序量比较大，但便于代码的维护，如果你的业务逻辑发生改变的话，你就需要多处更改你的代码，如果你将数据层和业务层分开的话，你只要修改一处就ok了。。。。
如果嫌麻烦可以使用框架啊
hibernate 增删改查对应的方法 save，delete，update，query


可是我一个save就涉及10……
[/Quote]

我的意思是说：一个save函数（一个事务）里面包含10几个SQL，我如果用ibatis的话是不是要在XML写10几个SQL？然后最重要的是不是要写10几个接口函数？最后把这10几个接口函数（实现了得）装配到一个save函数（一个事务）里头？

问的也不知道对不对！！见谅！！

[24K純帥]

那你的很多SQL有没有什么关联，要不要事务的

[sanshizi]

一个save就涉及10几个SQL呢 ?!!

这样的逻辑直接写在存储过程里面得了,

[贪睡的兔子]

分层主要是为了 维护方便 不能为了方便全部堆在一起

写代码本来就是类似于 搞艺术么

[sense]

[Quote=引用 22 楼 dikeboy1234 的回复:]

分层主要是为了 维护方便 不能为了方便全部堆在一起

写代码本来就是类似于 搞艺术么
[/Quote]

可是开发不方便了！！！

[forgetsam]

如果你那一个save真用了十几个SQL而不是你自己脑补的

就照你的方式写，真正需要分层的时候，不用别人要求，你自己就主动封装分层了。

分层是为了维护方便，逻辑清晰，代码无耦合，如果不分层照样有这个效果，那还分什么层

[xuguiyi100]

一个save真用了十几个SQL，用存储过程效率高

[sense]

[Quote=引用 19 楼 leehomwong 的回复:]

那你的很多SQL有没有什么关联，要不要事务的
[/Quote]

有关联，不一定多要事务