【读书笔记】搭建轻量级 Java Web 框架
书籍
博客地址
Smart Framework：轻量级 Java Web 框架
https://my.oschina.net/huangyong/blog/158380
既然没有弯路，那么什么才是捷径呢？那就是尽可能的简单，通过惯例（Convention）而不是配置（Configuration）
PowerDesigner 画的类图
黄亿华 2013/09/24 13:20
引用来自“黄勇”的评论
引用来自“陈春伟”的评论
连续看了几篇文章了。这篇也由的想说几句。一定程度上看，你的思想又要倒退了。退到了错误码时代。其实异常的提出，倒不是说是用来取代错误码的。错误码有它的应用场景，在异构平台的rpc等交互时，错误码有它的优势和通用性。但是错误码的缺点也明显。1、默认忽略性、需要人的主动性。2、不能跨作用域传送，无法冒泡传递，如果需要把持久层更底层的错误传递到UI，需在反复的手动（当然可以用工具类）包装往上传递，3、它缺少堆栈的包装信息，如果为了查错需要。需要自己包装堆栈。4、异常能独立于返回值独立成体系，方便统一的捕获（AOP）来处理。给关注分离带来好处。合理的使用异常和错误码才是更正确的选择。异常体系是每个高级语言非常重要的组成部分，为什么每个语言都设计了强大的异常体系，证明了它在面向对象世界里的位置，所以一旦你对某种体系有比较大的怀疑的时候，一定要想办法理解它更深层的用意。这样更有利于你去选择。这个纯个人感受。不代码对楼主的评价。
感谢您专业的评价！没错，其实我写这篇文章，并非是否定异常处理，而是想让大家知道，通过错误代码也是可以解决问题的，尤其是在 Action 里面，由于 Action 是处理业务逻辑的，如果混杂了大量的 try-catch，势必会让人无法关注在核心的业务逻辑上。什么地方应该用异常处理，什么时候应该用错误代码，需要根据不同的场景来做出选择，这是我想表达的。
这位哥们写的很全面了，提一点个人看法吧：
就如所说的，错误码在异构平台的交互就比较有用，例如Ajax的Action层面，我觉得Struts的返回值就是这种思想。Action往外就是前端了，定义异常也没有意义，错误码反而把所有情况都限定好了，更合理一些，一句话，不折腾！
另外，返回码更适合API双方约定的能预料到的错误（业务中的错误），如果一些IO异常之类的东西，我觉得还是异常更合适。
另外之二，Java中的try-catch确实非常破坏代码结构，特别是涉及到变量作用域的时候更加丑陋，需要写很多"Type value=null;"这样的声明，看不惯也很久了。
、、
jforum的确很不错，算是java方面一个标准的web项目，权限全部是配置成一个权限串，每个action里面会去判断，它那个多数据库支持我还是觉得有点麻烦，针对每种数据库都需要写一套dao和sql
LFU的关键词是Frequence，淘汰标准是一段时间内的使用次数。而LRU的关键词是Recently,是淘汰最长时间未被使用的。一个是淘汰淘汰最长时间未被使用的，一个是淘汰一定时期内被访问次数最少的。
作为一个简单的缓存，阁下的设计已经相当不错了。如果非要再做一些改进的话，还是有一些着眼点的，比如：
- CacheFactory的getCacheManager不是线程安全的，因此导致调用者createCache非线程安全
- 从API设计上，个人感觉CacheManager更像CacheFactory的实现，因为所有Cache的构建和销毁都委托给了CacheManager, 而CacheFactory本身承担的职责并不多。所以这一点上：一种方案是将CacheManager接口合并至CacheFactory，或者说抽象一个CacheFactory的接口，并将CacheManager作为默认实现。当然，如果在将来其实没有太大可能出现其他实现的话，省略掉这个接口也是可以的，要看你自己的打算了，避免过于接口化也蛮必要的。
另外，API的访问权限也可以做一些合理的控制，比如：CacheFactory的getCacheManager更偏重于内部实现细节，可以声明为private的。API设计的其中一个原则就是尽可能的降低API的可见性，这样在将来的细节变更不会影响到客户端代码。
