载自：
即使对于一个大部分基本逻辑都包装在标签/类/servlet/EJB中的网站，以至于在jsp中看不到任何的javalet代码，随着规模的扩大和项目
时间的延长，目录中总是堆满了越来越多的垃圾文件。有些文件本身不是垃圾，而是被包容的子文件，但是jsp服务器可不管这个，如果不是jsp后缀，它就会
被jsp把源代码下载到客户端；或者，同样是jsp一样时就让维护者头大。如果不是采用良好的文件策略，那么随着规模的扩大，一般的中大型站点堆出几千上
万的jsp文件，其中每一个模块分上几十个，是非常正常的；这时侯，管理这些文件就成为一件艰苦的工作；事实上，如果不是多人分管的话，一个发布管理员真
正能够维护的文件如果超出一百个，效率就会急剧降低。何况，还有更重要的sql文件，class文件，xml设置文件……。为什么总是努力使用
bean/fragments/标签/ORclass（如EJB），这就是原因之一。事实上，从事过大型项目的开发员对于后期目录中那种不知那个有用那个
无用但却要么不管要么只能一个个识别的经历，总是一种难言的痛苦。经历过这种痛苦也会对可重用组件在项目中实际上降低了后期维护费用的感受良深。
要实现高度的重用性，减少需要维护的文件的数量，就需要对系统架构甚至前台框架都进行抽象，重用的方式除了Class等方式外，还可以使用
shellscript帮助，特别是对那种必须分割出目录管理而实际上结构非常相似的类型。通过这个办法，即使是很大的项目，也可以把需要维护的jsp文
件，不含java类库压缩到一百个以下，包括用于包含的小jsp片片fragments。
良好的命名规则可以进一步提高对文件的识别，也便于使用shellscript按文件类型进行管理。为了防止被jsp服务器下载到客户端，如果是与
apache结合的话，可以在apache中建立禁止下载的文件类型。我一般是把这种文件命名为jsp_，为了达到这种命名的规范性，甚至不惜把已经写好
的程序改一遍，幸好，在良好的组织框架下，文件总是只有几十个，并且只需要改一两行的几个字母。尽管如此，每次都仍是让我感到生畏，这种规范工作的确是最
不令人兴奋的。
建立良好的命名规则和目录结构，也是为了可以有效重用已有工作的前提，但什么时侯应该达到重用呢？毕竟即使是很相似的框架类型，在面向重用要求时，就意味
着很多的if-else。logic:equal/present之类，在Class中可以通过接口和继承实现代码的高效率，而在JSP中，如果重用变型
达到三个以上，大量的if-else之类就令混帐代码冗余广泛伸延，而在jsp文件内部令维护难道大大增加一个档次；或者一个简单的要求就需要
include十次八次，同样是加大了维护成本。（要知道，接手者，甚至是自已吧，过了几个月，对于开发中的印象早就消失干净了。）
这是一个难以协调的问题，可以调整的空间很小：如果不重用而一个文件任务专用，意味着每次需求变动时要重复维护多个非常相近的文件；超过三个的话，也就等
于说这个文件建立方式是低效的。而如果文件复用的话，依靠在jsp中的判断实现，那么文件变得难以维护调试的界限也是三个左右。希望把这种代码包含进
Bean是愚蠢的选择，Bean不是做这些事情的，原则上，非表达层只应该包含业务逻辑，不应带有任何专用的表达层代码，象html。
问题的焦点在于，JSP作为表达层的实现方式，本身缺乏对象抽象的能力，只能依靠在jsp中的逻辑判断适应条件变化；而理想的MVC，view视图需要的
是一个定义视图表达形式的对象，jsp根据这个对象的设置生成框架需要的html代码，甚至生成jsp本身。因此，实际上对于这种大型的站点来说，在数据
库以及数据映射和业务逻辑的中间层以上，表达层以下，需要的是一个jsp的发布系统。这个发布系统根据用户自已定义和开发的框架抽象，生成jsp目录/文
件等。它到底应该如何运行，我还没有明确的解决方案，不过这个系统会有用的。
Cocoon是另一种发布系统，不过不符合这个要求，他事实上是一个与目录无关的xml转换器，可以根据用户定义的xslt转换器以及客户请求的文件类
型，通过不同的转换器向用户提供同一内容的不同文件类型，xml,html,pdf或者其他。事实上，由于在互联网上存在着文件类型统一化和归一化的自然
趋势，因此，为了少量用户的特殊文件类型要求让系统增加一半成本，减慢一半以上的速度，只能处理少一半的文件，加了这么一个转换层是否值得我是深表怀疑。
象特定类型的数据必须提供xml，（如SOAP），直接用servlet写的应答程序就可以看作是一个全功能的转换器，又何必另外再搞一个转换器和控制器
来处理这种要求呢？除非所有文件都必须同时提供 xml/html/pdf，否则象cocoon这种框架，我相信是毫无意义的。
