6618自助建站系统源码浏览器看b站

       一谈到搭建框架，入门级别的人会觉得你很牛叉，崇拜。稍微有点工作经验的呢，则心里会犯嘀咕，不就是SSH 那一套吗？特别是参加过培训班那种的，估计更加明显。再年长一些的工作五年之久的，对框架理解可能会偏向业务，把业务的因素考虑进去。到我现在的层次，已经不再关注业务，而是单纯的一种程序设计。这种设计灵感来自于Apache下的一些小玩意触发，这是种子，就是看了Apache commons 下的 chain不是很纯的责任连模式，慢慢改造而来的，为何框架已定要针对制定的业务呢？所谓的业务呢？再我理解看来就是软件需求，例如政府行业有政府行业的软件特色，金融行业有金融行业的软件特色，电信移动行业等都有自己的特色的东西。大家能建立在如此的基础上，说明已经混迹了不少年了吧，在软件行业。但是大家是否想过，无论这些行业在如何有差异型，用的技术提携基本上都是一致的，就近些年的技术基本都是SSH、SSI抑或Spring全套。（我写着文章时是不考虑互联网公司的，因为没有参与过，也无法知道其技术内幕，那些技术不是靠SSH能搞定的，Java的内存是他最大的软肋）。
       好了 又开始提到一些题外话了。难道写那些基础框架的人也考虑其业务的东西，估计业务通用到各个行业的软件开发中，究竟是他们的框架有何魔力，居然可以适用于大多是地业务场景。在你考虑搭建自己的开发平台的时候，是否静心考虑过这些业务之外，纯粹的软体设计呢？例如我最熟知的Spring家族，目前对Springframework、batch、webflow、acegi等都有比较深入的了解以及实践（一些是自发的研究）。如此精美的框架体系是如何被创作与完善的。这个是需要认真思考的问题。大家都知道Spring的核心技术是IOC，为了了解这玩意的工作机制，基本上把代码都看了一遍，其内部的复杂性还是借助思维导图软件才理解清楚的。但是让我自己是无论如何也无法写出如此精致代码。完美。
         说起另外一点了，一谈到软件架构，大家的定向思维都是往宏观角度去考虑，架构让人联想到底是什么呢？例如集群支撑、消息通信、高并发控制、监控体系，可扩容性、安全性。架构还涉及到数据库的构建。没错的，大家的思维很正确，这些的确是作为一个架构需要考虑的，但是J2EE经历了如此漫长的技术发展，这些针对性的基本都有了中间件的支撑，例如集群有JBOSS、Tomcat等、消息通信有MQ、Socket。高并发在我看来Mina与Netty都是不错的选择，多线程应用最近很火爆的JAction据说很厉害，还没有研究过，采用回调机制的多线程技术，应对的通信层决定他的速率。监控的话有JMX等、扩容与安全性则暂时不讨论。分布式我也没接触过。大致如此把，都是很成熟可以使用的一些技术体系，无需自己从底层开发。开源的世界，讲究拿来主义， 。
       最近自己也开始针对上面的问题进行思考，考虑没有业务因素干扰的架构如何开发，宏观的问题已经有开源的技术帮我们实现，下年所要做的就是基于微观的架构，这一点估计大家都有所忽略。这种架构与MVC、IOC、DAO都没有关系，因为这些是为了解决程序开发特定领域内的技术实现，严格讲都是一种框架体系， 这些年来，我自己也陷入如此的一个怪圈，这也与我自己的工作经历有关系，工作经历决定了你能达到的高度与广度。在这里很很感谢之前的公司，成就现在的我。
        大家应该都重程序设计本身考虑，例如程序流程图，这是大家一开始学习程序软件课程学习的东西吧，但是这也是被大家所忽略的，因为它在现在的程序世界，是被忽略的一个角色，各种框架充斥着你的眼球和大脑。 纸上谈来终究觉得不行，凡是需躬行才可以，就目前而言，脑袋中大概有这样的一个想法，但是却找各种理由拒绝实践，这样是不可取的。  
         现在自己动手写写，发现很多细节的问题需要处理，不过还好，解析的引擎比较细致的出来了，采用Apache 的 Digest 作为解析引擎。还是能比较完美的处理这些比较有规则的XML文件。但是解析完之后如何多这些建模到内存的数据进行使用呢？

      那些是执行的业务代码，那些是流程控制代码。这个还需要自己研究下，目前我还没有相处一个好的方法，对这些存储于内存中的原始数据如何解释成可运行的语言。

      一切从最简单的入手，也许这样的想法是OK的，至少让我在一开始的时候不至于收到太多的打击和挫折，整理下思维，如何做好编译这些数据是关键。编译原理没少看，但是如何搭建一套所以自己的引擎内核，目前自己还是一头雾水。需要考虑的东西太多了，总觉得那里部署很完美，存在那么一点缺陷，导致一切都很别样，苦苦的思索，