通过这几天的 框架学习我认为在处理一个具体的业务模块的时候,我们可以考虑一下因素
- 日志
- 跟踪,调试,信息,警告,错误 如果能严格的按照这个 5个等级来,就能查看出程序的任何错误,一段优质的代码 80% 使用来处理错误,5% 是用来记录日志,真正用来做业务实现仅有 15%。
- 异常
- 程序出现异常 就会 涉及 异常处理
- 记录异常
- 统一异常
- 重复执行,绕道而行
- 事务回滚
- 程序出现异常 就会 涉及 异常处理
- 事务
- 性能
- 同一个资源被反复读取,没有放入缓存中。
- 简单的问题,复杂化。
- 在代码没有任何多余的情况下,硬件资源消耗的情况下,业务逻辑合理的情况下,考虑是否需要通过 分布式,集群方式实现
- 国际化
- 验证
- 监控(可以通过 Spring aop 实现)
将这个 业务的 每个任务执行的状态(可以具体分为几步) 记录下来,每次执行完成都去改变状态,那么就可以动态通过网页 监控这个状态。- 监控执行状态
- 监控执行时间
- 监控异常
- 监控事务是否回滚
- 生命周期
- EJB
- 考虑给业务模块一个上下文
- 考虑业务模块是否能封装成EJB, 通过MVC 的 控制层 与 EJB 交互。
- 会话bean
- 消息驱动bean
- bean
- JMS
- 设计模式
一个业务模块下,应当多从这 几个 因数 出发想一想,不要立马动手去做。目标就是能把代码写好,不用改bug,也不会出现任何问题。就算出现逻辑问题也能通过日志看的清清楚楚。出现性能问题,也能通过监控看的清清楚楚。
我发现所有的框架都会,一下几点相似
- 上下文 context
- 记录整个框架的 公共的资源,生成不同的组件
- 生命周期
- 框架由不同的组件组成,而组件一般都会有生命周期
- 会话 session
- 与框架组件交互时
- 框架 bean
- 框架组件特有bean
- 建造者,工厂,代理…等等一些列的设计模式