我对春天相当陌生。谁能告诉我 spring 配置文件驻留在 MVC 的哪一层。根据 M、V 和 C 的定义，我认为它应该是控制器层，但我不知道它是否正确。
我不确定这真的是一个答案，但评论太长了。
我认为认为MVC过于僵化是无济于事的。 从历史上看，它(比大多数人知道的要早得多(作为关注点的分离而出现。 这种范式至少比网络早 10 年。
当最终用户设备开始有足够的大脑来完成有用的工作时，很明显，仅仅因为你的PC(不是那么笨的终端(可以存储程序代码，它就不是进行数据库调用和交付结果集的正确位置。 我见过的第一个客户端-服务器应用程序之一，就是一个绝妙的主意，即将所有可能的客户下载到无盘 unix 工作站上的选择列表中。 不幸的是，该客户列表超过100,000个条目。 不用说，效果不佳。
我所知道的第一个关注点分离是可追溯到1980年中期的IBM哲学。 2 层或 3 层模型中应用程序的每个部分都拆分为可以划分的不同服务。 他们是：
- 演示服务(又名视图(
- 应用程序服务(一般实用程序功能(
- 应用程序逻辑(又名域;又名控制器( 数据
- 操纵器/数据状态控制器(又名模型(
阳光下的新想法如此之少，真是太神奇了。 名称会更改。 这些概念没有。 上面列表中缺少的主要内容是服务接口(又名Spring @Service(。 他们尚未为应用程序逻辑划定明确的入口点。 此外，应用程序服务在被调用时失去了重点，只是溜回它可能所属的 UTIL 文件夹。
至于你的问题，默认情况下@Configuration东西是MVC的控制器。 不是因为其他腿可以自己站立，而是他们不能。 但因为它显然不是模型或视图。
您可能会从阅读有关Spring PRE Spring Boot的信息中受益。 就我个人而言，我真的很不喜欢Spring Boot。 这是IMO放弃对环境控制的桥梁。
关于多种背景和亲子关系，确实有一些令人着迷(至少对我来说(的事情需要了解。 这不仅仅是一个完全学术性的练习，如果你正确地将模型和控制器的东西与你的视图的东西分开。
我也喜欢使用Spring Profile来交换Oracle和H2，这样测试就可以在正常的人类生命周期内完成。 更不用说可重复性了，直接数据库访问几乎肯定不是。