1700485500
1700485501
}
1700485502
1700485503
}
1700485504
1700485505
public String getViewPath（）{
1700485506
1700485507
return viewPath；
1700485508
1700485509
}
1700485510
1700485511
}
1700485512
1700485513
DOM4J提供了VisitorSupport抽象接口，可以接受元素、节点、属性等访问者。我们这里接受了一个元素访问者，对所有的元素过滤一遍，然后找到自己需要的元素，非常强大！
1700485514
1700485515
我们继续分析，在IoC容器中都会区分对象是单例模式还是多例模式。想想我们的框架，每个HTTP请求都会产生一个线程，如果我们的Action初始化的时候是单例模式会出现什么情况？当并发足够多的时候就会产生阻塞，性能会严重下降，在特殊情况下还会产生线程不安全，这时就需要考虑多例情况。那多例是如何处理呢？使用Clone技术，首先在系统启动时初始化所有的Action，然后每过来一个请求就拷贝一个Action，减少了初始化对象的性能消耗。典型的原型模式，但问题也同时产生了，并发较多时，就可能会产生内存溢出的情况，内存不够用了！于是享元模式就可以上场了，建立一个对象池以容纳足够多的对象。
1700485516
1700485517
1700485518
1700485519
1700485521
设计模式之禅 38.2 最佳实践
1700485522
1700485523
本章我们粗略地讲解了一个MVC框架。一个MVC框架要考虑的外界环境因素太多了，而且本身MVC框架也是一个轻量型的，就是希望我们编写的程序在没有Struts、Spring MVC等框架的环境中不需要大规模的修改照样能够运行，所以编写一个框架不是一件容易的事情。幸运的是我们以学习模式为主，通过设计MVC框架来了解设计模式。我们来看看本章用到了哪些模式：
1700485524
1700485525
❑工厂方法模式
1700485526
1700485527
通过工厂方法模式把所有的拦截器链实现出来，方便在系统初始化时直接处理。
1700485528
1700485529
❑单例模式
1700485530
1700485531
Action的默认配置都是单例模式，在一般的应用中单例已经足够了，在复杂情况下可以使用享元模式提供应用性能，减少单例模式的性能隐患。
1700485532
1700485533
❑责任链模式
1700485534
1700485535
建立拦截器链以及过滤器链，实现任务的链条化处理。
1700485536
1700485537
❑迭代器模式
1700485538
1700485539
非常方便地遍历拦截器链内的拦截器，而不用再自己写遍历拦截器链的方法。
1700485540
1700485541
❑中介者模式
1700485542
1700485543
以核心控制器为核心，其他同事类都负责为核心控制器“打工”，保证核心控制器瘦小、稳定。
1700485544
1700485545
❑观察者模式
1700485546
1700485547
配置文件修改时，不用重启应用可以即刻生效，提供使用者的体验。
1700485548
1700485549
❑桥梁模式
[
上一页 ]
[ :1.7004855e+09 ]
[
下一页 ]