spring boot 项目结构

之前写了个hello world,感觉spring boot的项目结构也就spring mvc那样,挺好理解的。

现在才知道和spring mvc有些不同,需要更正。

 

一、我感觉比较正确的项目结构

结构如下:

1

有点像spring mvc,因为打算整合mybatis,所以按照习惯分了pojo、mapper、dao三层(用于数据库操作),service层用来处理具体逻辑和借口,controller用来处理请求。

感觉spring boot和spring mvc最大的不同有两个:

1.不需要任何的xml配置

只需要在启动类上添加注解:@SpringBootApplication即可。

这个@SpringBootApplication注解取代了spring mvc中扫描并且加载的一系列配置,比如说控制spring中ioc和aop的spring.xml文件和spring mvc配置的spring-mvc.xml文件。

优点是配置非常简单,一个注解把所有配置文件的工作全都做了,有利于尽快写出服务,进行敏捷开发。

缺点是封装得太过完美,如果对spring框架没有深入了解,很难知道配置中发生了什么,为什么会这样,实际发生了bug会很难排错,如果想要自定义功能也是难上加难。感觉spring boot这样的配制方法实际上是提高了下限,但是提高了上限。变相增加了使用难度。

所以我认为,最好不要通过spring boot上手spring系列框架。否则很难知道这个框架大概是怎么运作的,个人建议至少亲自搭建一次spring mvc,才有可能有一个基础的了解。如果只是会用但是不清楚原理,对一个开发人员来说实在是太可怕了。

其实spring boot也是支持xml配置的,完全可以像spring mvc那样去配置spring的各个模块。为了详细了解这个框架,虽然挺矛盾,但是我觉得这样做是值得的。

如果有机会,我将尝试使用xml配置一下spring boot。

2.启动类需要单独提出来,写在根目录下

就像之前提到的,这个启动类是为了启动内置服务器的(现在的spring boot好像支持外部服务器启动了)。

Spring Boot会自动扫描@SpringBootApplication所在类的同级包,以及下级包里的所有bean。所以建议入口类放在最外层的包名下。

目前感觉比较大的区别就在以上两点。

二、最好不要依赖框架

上面也提到了,不了解框架的原理,仅仅会使用,是非常危险的。万一出现了无法解决的错误,凭借个人对框架的理解,要怎么去排错并且修复呢?

所以我建议,至少要对框架有了一定的了解再去使用,否则开发还是要以稳定可靠的方式为主,防止发生预期外的问题。不能说看到什么东西有优点,就尝试加在项目中。至少要弄懂原理(不能说精通吧),才去使用。

这个其实是我自己的反思。我也不敢说自己对ssm了解得有多深,只是使用得比较熟练而已。说到底,这只不过是一个工具而已。之前我把自己的知识建立在工具上,感觉将会学得很肤浅:一直用别人封装好的东西,很值得骄傲吗?万一有需求要你去写个同样的框架,你能写得出来吗?

所以我个人认为,这涉及到一个学习方法(态度)的问题。最好还是尽量使用底层的方法去实现(mybatis实际上也是对jdbc的封装…)。如果要使用spring,可以,但是你看过源码吗?spring是怎么实现的?用了哪些设计模式?为什么要这样写?和传统方式想比,使用spring有什么优越性?如果让你去实现一个spring,你要怎么去做?你能实现一个spring吗?

我估算了一下,要解决以上的问题,至少要懂得调试代码、java的注解反射动态代理等高级特性、设计模式、jvm底层知识、数据结构…这就是我只敢说我只是会用的原因。

其实我也不是说只会用框架就怎么怎么肤浅,只是扪心自问:这些问题是你提高自我的路上必须要解决的,或早或晚你都会面对的。如果停止思考,那么你就不能提高了,你的程序员生命将提前结束,仅此而已。

总之,造轮子是很好的学习方法,多去思考,多去造轮子吧。

三、总结

希望我自己能达到这样的学习目标:不只是会使用spring boot而已,更要了解spring boot的运行原理,甚至能提出更好的解决方案。

多说无益,还是尝试着自己去造造轮子吧,肯定会有不少的收获。

发表评论

电子邮件地址不会被公开。 必填项已用*标注