J2EE系统中的数据文件可以分为两类：
1.编写代码时确定的
静态文件，只能由开发人员手动修改，相对固定。如企业内部网站主页上通过固定超链接引用的“请假单.doc”
2.系统运行时产生的
动态文件。这又可以分为两类：
a.文件产生后，需要作为业务数据一直或长时间保存。如 BBS用户发贴时产生的附件文件。此类文件可称作
较持久的业务数据文件
b.文件产生后，即时应用，即时作废。如大流量I/O时为了减少内存消耗而临时存在的缓存文件。此类文件可称作
临时数据文件
这些文件应该放在何处？是否应该和
源程序中的其他物理实体(.class文件,jsp文件l等)杂揉在一起？ 个人认为这受到软构件部署（从开发环境发布到生产环境）和系统分布式运行的制约。以下按文件类别逐一讨论：
1.静态文件。这类文件可以当作代码，和class文件、jsp文件一样，不受部署方式和生产环境
的影响。比如说，部署时可以和class文件一样直接复制，如果系统采用分布式运营，这类文件在各机器上都可以保留相同的副本。因此静态文件可以与源程序杂揉在一起
2.动态文件。
a.较持久的业务数据文件。
I.在开发环境进行单元测试时可能会产生一些业务数据文件，这些文件不适于拷到生产环境，如果这类文件和源程序中的其他实体杂揉在一起，那么部署前就要先拣出来删掉，此举无疑增加了部署的复杂度。因此，此类文件不能和源程序放在同一个目录中。
II.此类文件往往被分布的各个程序共享使用，或者将来可能会被共享（如当前的单台WEB服务器以后可能要做集群）。因此，此类文件在就不应入在系统某一进程专属的机器上，而应放在一个独立于任何进程的机器上，如一个独立的FTP服务器，但这样做的代价是
额外添加了一个服务器的维护量，并影响物理架构
b.即时失效的临时文件
I.若考虑部署方式，应与 持久业务数据文件 的处理相同，即不应与源程序保存在相同目录中
II.若考虑分布式运营，应于此类数据文件为临时文件，不可能为多进程共享，因此与使用它的进程可以放同一台机器上，如c:\temp。不过，如果一个系统中既有持久业务数据文件，又有这种临时文件，为了让运维人员觉得清晰，仍可以考虑采用独立于任何进程的文件服务器。这样做的代价是加大了程序设计的复杂度（远程读写文件的代码比本地读写文件的代码要麻烦一些）
结论：
1.静态文件当作*.class,*.jsp文件处理，
可以与源程序杂揉在一起
2.动态文件
不能与源程序混杂，并视持久程度，决定是否要放在一个
独立于系统各进程的文件服务器中