编程中的各种闲谈

意味着任何一个功能都应该有权限来访问所有的 entity，这块是否应该独立出来呢？

service 是否一定要定义 interface

在学习ssh(spring, struts2, hibernate)时，老师教在 service 层要定义接口，再去实现此接口，方便解耦。

在 spring 框架中，自身定义了很多接口，并且有不同的实现来完成不同的任务，实现了很多灵活的设计。

那么我们定义的 service 是否也会被用来被多次实现呢？没有，在我编程的这几年一直就是一个 service 接口只实现一次。

那么为什么我们还坚持需要 service 接口呢？并且在使用 ide 的时候不能直接定位到方法内容也是个很尴尬的问题，何况还得去维护两个类呢。

所以近几年我编写的框架中抛弃了 service 接口的定义。

当然这并不是说接口没用，例如我通过配置使用不同的service实现来实现不同业务规则。在目测只有一个实现类的情况下不认为添加接口能带来灵活。

Entity 是否要跟模块一起

近些年接触的项目以及自己实现的都是这样的结构，定义一个功能模块包，包下面放 controller, service, entity, dao 等包。

大多数的功能在本模块包定义的类中都能够实现，但问题是总有一些功能是需要其他模块包中的 dao, entity 的。

复杂的业务逻辑会出现更多这种情况，有时看到会出现 service 调用，之前认为 service 调用没什么，最近遇到一个项目 service 调用后都很难找到业务，

开始思考这种实现是否合理。service 之间调用是不应该的，一个 service 应该完成一个完整功能，而出现在两个 service 去实现子功能那需要考虑是否应该重新设计 service。

dao和entity 是整个项目可以访问的，处理所有实体或者数据库的所有对象，意味着任何一个功能都应该有权限来访问所有的 entity，这块是否应该独立出来呢？

人们或许首先想到的是同一个文件夹下文件多，那么慢慢被许多人接受的 mybatis 的 mapper 文件放在 resource/mapper 文件夹下，也感觉越来越适应了。

如何获取当前用户信息

当然也看过写到 service 层获取信息的，这显然是不合适的。

spring mvc 会解析请求数据，然后给参数赋值，那当前用户信息能否采用这种方式获取呢？给spring mvc 一个解析器就可以。

关于吐槽别人代码

经常看到有吐槽别人代码的，有时我也会，通常因为代码写的非常飘逸，设计差等原因。

但是想想吐槽完之后知道怎么去改善吗？或者说当时头脑一想应该如何处理，但是这个“想法”真的就是真的好方式吗？

当开启下一个项目的时候，你会将自己以前在吐槽别人代码时产生的好想法加到自己的项目中去吗？还是说以前项目就是这么做的，我还得沿用？

积累自己的好想法，应用于之后的编码及下一个工程。若是在本项目无法做出的改进，那么下面的项目就应改变，沿用以前只会让下个人再来吐槽你。