sql是不是可以写在service层?虽然service是业务层
我记得我曾经学javaweb的时候,也是被这个问题困惑过大半年,service层到底要不要出现sql或者Hibernate的hql语句?
我曾经有和你一样的困惑,比如有一个UserDao的接口,假如我想查询User,根据Id查询可能UserDao就需要设置一个findUserById(Integer id)这样的方法,根据用户名查询就是findUserByName(String name),根据邮箱查询就是findUserByEmail(String email),可能我还需要一个模糊查询,根据用户名模糊查询findUserByNameLike(String NameLike)等等,如果我的查询条件很多,我很有可能会在UserDao里面设置很多个不同的方法!可能会导致这个UserDao的小方法泛滥的多!我当时就想,能不能UserDao里面只设置一个find方法,然后sql语句和参数都由service传入,那么这样,UserDao岂不是非常清爽简洁啦?比如findUserByQuerySql(String querySql,Object... params),service业务层负责传入sql查询语句和参数,UserDao执行通用的findUserByQuerySql就行了。
我想,听完上面我说的这段,你一定泪流满面想和我握爪,就像找到了战友一般是不是!!
不幸的是,这种方案很快就被我当时的老大否定了!!
采用这种所谓通用Dao从service接收参数的方法在大型团队中会有以下几个严重问题!
1,假如你在多个地方中调用了这个通用的findUserByQuerySql(String querySql,Object... params),很有可能你的sql语句会在service中重复,举个例子,假如你在多个地方需要通过用户名模糊查询用户,那么,每个地方,你都需要准备完全一样的querySql(参数可能不同)。也就是说,你的service层的代码会重复!你就会在多个地方复制同一段代码,如果哪一天模糊查询的方式改变了,你需要把所有涉及到此查询条件的sql语句都给找出来一个一个来改变!!在大项目中是不可想象的!(Dao模式中是把sql封装到dao的方法中,那么,相当于只要调用这个dao方法就复用了方法里面的sql)。
2,涉及到多人合作问题,你可能现在是一个人做项目,感受不到,如果项目很大,是多个人合作,你的这个通用的UserDao被多个程序员调用了,假如,我为了一个很复杂的查询,光思考sql结构都思考了老半天(不要以为sql查询就是简单的select from,我曾经见过单条100行以上的sql查询语句!),嗯,我花了大概30分钟搞定了一条复杂的sql查询,另外一个程序员恰好也需要这个功能了,这个时候,他可能也会在那里想同样的一条sql查询啊!!结果他想了2个小时才搞定,你说浪费不浪费???这还不算什么,很有可能你们对于同一个查询写出来的sql语句是不一致的!!甚至有些人写的是正确的,有些人写的是有bug的,那么,极有可能出现你们两个人对于同一个查询不一致的情况发生!这都还不算事,最恐怖的就是,如果涉及到的查询由于业务原因发生变化了,那么,每一个人都去代码中捉虫子去吧!!结果再来一次每一个人都一套自己的sql,这种糟糕的局面会像滚雪球一样,越来越严重。(采用Dao模式,只需要一个sql高手把同一个查询的sql封装到dao的方法中,所有需要此功能的只需要调用此dao的该方法就行了)。
你的本意是想让UserDao更简单点,最好只有一个通用的查询方法,出发点是好的,但是,我希望你明白一点,不是东西越少就越好,就像java程序一样,本质上都是从main方法进去,main方法出来,我把全部代码放在一个main方法,弄他个30万行,有没有问题?依我说,没问题,jvm不会拒绝的,一样执行。这样整个程序只有一个方法呢,是不是越简单越好呢?可实际情况是一个大型项目中,所有类的总和都会有上千甚至上万个,大家各司其职,把业务拆分到单元中,说的专业点,就是面向对象三大特性之一的封装了。
Dao是数据访问对象,一个业务逻辑不仅仅是访问数据,应该说,数据是业务逻辑的一个底层支撑,举个例子,把你的日常生活看作你的业务的话,那么,一日三餐饭就相当于是你的业务活动的支撑了!我们在论坛交流的目的不是为了把问题文章存到数据库中好玩,而是为了和其他人交流,实现论坛的商业或非商业需求,存到数据库的唯一理由是为了持久化,好让你明天登录还能看到你的帖子,或者其他人能够发现你的帖子!持久化本身并非是商业活动意义上的业务逻辑,他只是为了能够提供更好更智能的商业业务而设置的一个基础设施,否则,一个发了帖子第二天就看不到的论坛,谁会去用呢?
可能对于业务逻辑的概念你还是很迷糊,我再举个例子,假如现在有一个网站系统,“每天首次登录就会送10个分,重复登录不送分,发一个帖子送50个分,如果帖子被置为精华,送1000个分,如果用户捣乱犯规,一次扣500个积分,犯规三次或积分小于0,锁定用户”,注意我用引号引起来的部分,这是一个论坛逻辑,这就是一个论坛经营过程中的业务规则,这些东西都需要在service层中去实现的!只不过Dao层,对于上述业务提供了数据持久底层支撑。如果有一个神存在,它可以监控所有的数据并记在脑子里,我们就可以不需要数据库了,需要什么业务就去找神询问就行了。这个时候我们的Dao可能就变成GodBrain(神的脑子)这样一个对象呢,获取用户积分就是GodBrain.getUserPointsByUid(Integer uid)。
回到你的问题本身,把sql写到service层是不行的(如果有程序员反驳我的观点,我只能说,你做的项目太小了,或者根据就是一些纯忽悠的辣鸡项目,你根本不知道什么是大型项目的有价值的项目了),那么怎么控制Dao层中太多的小方法呢?
我觉得可以这样做,还是以UserDao为例子,我们还是设置很多个小的琐碎的查询方法,比如UserDao.findUserByName(String name),UserDao.findUserByNameLike(String nameLike),同时我们在UserDao中设置一个通用的private的私有find(querySql)方法,findUserByName这样的方法不做具体的查询工作,而只是根据用户传递进来的name啊nameLike等参数生成sql语句,生成sql语句后调用Dao中的private的find方法,这个find方法是一个通用的方法!
通过上面的解决方法,可以将Dao中的重复代码降低到最小。
你能够在这里发这样的帖子说明你是一个爱思考的人,慢慢学吧,不要轻信菜鸟同事的说法,或者大部分人的看法,多读点书,特别是那些被大家公认的好书,说句不客气的,程序员之间的差异比人和猴子之间的差异还大,所以网络上一些人告诉你的很有可能是错误的。
解决问题还是看实际需求,耦合不耦合也是看实际需求的,我很不喜欢一些人一上来就否定这个,说这个辣鸡,那个辣鸡,举个例子,你自己开个杂货铺,你有必要成立采购部,销售部,财务部吗?你有必要采用MBA的管理方式吗?显然是不需要的,但是你要是开个大企业,你就需要了,因为大企业涉及到的也无太大,人员太多,业务越复杂,就越应该拆分,越应该把一个整体软件组件化,采用分布式子系统等,否则业务错综复杂,以至于单个项目超出了人脑子能够理解的极限,无论是维护还是可理解性上都是极其困难的。分而治之就是分层思想的一个体现,也是将复杂性包裹在一个组件中不让他扩散到外部。Dao接管了整个数据库部分,如果你们公司有人很懂sql的话,他们完全可以封装一整套Dao,作为业务开发人员,你连sql都是看不到的,你只需要使用它们提供的Dao的api就行了。这样,你在做业务的时候,你的业务中不会包含任何的数据库逻辑,因为所有的数据库逻辑都被围困在Dao中而不会扩散到外部,这样,复杂性就被管理起来了,就被征服了。
很多网友说,jsp一样能干,不分层也能干,是的,这是可以的,但是这仅限于小型项目或者试验项目。如果你想成长的更快,真的在软件业有成绩,一定要把分而治之这种思想理解到一个底朝天,分布式系统,集群,SOA,消息中间件MQ等,这些东西的思想都是想通的,不要因为一个人告诉你jsp也能干你就裹足不前了。
————————————————
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
原文链接:https://blog.csdn.net/y_dzaichirou/article/details/53673528