关于日志门面和日志实现的疑惑？

Question

不同的框架整合，比如spring springmvc mybatis的整合 它对于日志实现有要求吗
比如说存不存在某个日志实现框架不能支持的
如果不存在【本人认为是】，为什么不能直接在项目中使用同一个日志实现，而是会出现日志门面这种整合多个日志实现的东西

Answer 1

一句话解释的话就是历史遗留问题。

在 Java 生态里 Log 这玩意儿是先有社区实现、再有的官方标准，所以流行的社区实现就倒逼官方标准了，而且因为不止有一个流行的社区实现、而是有多个、这多个之间彼此还不兼容，所以就成了今天这个样子 ———— 谁让官方定标准定的太晚了呢。

所谓日志门面其实就是一个抽象层，抹平各个实现之间的差异。而“门面”这个词来源于设计模式里的“外观模式”（Facade Pattern），Facade 有“表面”、“正面”之类的意思，结果在设计模式里被翻译成“外观”，在这里却被翻译成“门面”了，怪哉。

在实际中项目外观模式也是一个很常见的设计模式。比如你有对接云存储的需要，经过调研发现市面上的云存储（比如 AWS S3、Azure Blob、阿里云 OSS、腾讯云 COS、七牛云 Kodo 等等）各自的 SDK 和 API 不尽相同，但项目里可能这几种云存储会换着用（比如甲客户指定要阿里云的、乙客户指定要腾讯云的）。那总不能来回改代码呀。所以就有必要提取出来一个抽象层，抹平各个实现间的差异，业务代码里依赖的是这个抽象层，而不是具体的实现，这样想换的时候只要改一处就可以了。

总而言之跟 interface 接口的作用比较像，都是为了抽象而不依赖具体实现嘛。但 interface 是自顶向下设计的，而外观模式是已经先有了底层具体实现、倒逼你在上层做抽象。

Answer 2

因为日志框架这么多，你不能保证所有人都用一种日志框架，有的人可能喜欢log4j有的人可能喜欢logback，java log 或者其他日志框架