Architecture

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.动态文件 不能与源程序混杂，并视持久程度，决定是否要放在一个 独立于系统各进程的文件服务器中

    请求文件中每个请求都带这样一个栏位，应答则将这个栏位原样送还。这样可以让程序迅速地匹配请求和应答。    要用附加键，不要用业务键。因为随着需求的变更，原业务键可能要与其他的业务键形成联合键，也可能该业务键已失去作为键的资格

如果把各字段做成一行排列在一起，那么当中间某个字段的长度改变、或者在中间增删字段时，其后面所有字段的位置也都将改变，这个文件的解析程序就要大改 如果用XML的话，字段长度、增删字段都不会有这种问题，只不过数据量会大很多，在网络传输中可能会影响效率

例： 在日终处理中，系统将每日自动清理如下数据： ? 超过保存期限的业务信息表记录； ? 超过保存期限的交易流水表记录； ? 超过保存期限的统计报表记录；

增删改查有啥好说的？     大多数功能模块，其主要逻辑可能都是数据项的增、删、改和查看。比如 系统中“用户管理”模块，不外乎用户资料查看、增删用户，修改用户资料等。 界面基本设计    在页面上，主要牵涉到的主要界面一般有(以用户管理为例)：      1.用户列表界面。把所有用户列出来，要分页，有必要的话还要放一个搜索输入框。列表中点击某用户，就可以进入该用户的明细界面，或者直接进入该用户的修改界面。列表的最下面或最上面应该有一个“增加用户”按钮。      2.用户明细界面。显示用户的详细资料，应该提供“修改”按钮，如有必要，还可以提供“删除”按钮和“返回列表”按钮      3.用户修改界面。在输入框中显示用户的详细资料，让管理员直接修改。此页面除了提供“确定”按钮，还可以提供“删除”和“返回列表”按钮。在很多情况下，有了修改界面，明细界面其实可以免除。      4.用户增加界面。一般是一系列空的输入框，管理员在这里直接设定用户资料。此页面除了提供“确定”按钮，还应该提供“返回列表”按钮。 其他问题     以上列出了最基本的界面设计，但是问题还有：       1.如果要批量删除，该在哪里删？       2.从实现的角度来说，增加用户和修改用户的界面其实差不多，逻辑也差不多（比如字段校验）。实现起来可能要写很多重复的东西，不但会增加开发人员的烦恼程度，而且在发生修改时，两边都要做同样的修改，这样很容易出错。       3.最关键的问题，增、删、改完成以后，应该跳到哪个界面？     下面一一讨论这些问题 批量删除在哪里删？     一般都放在列表页面。列表中每行的最前面搞一个checkbox，列表的最上面或最下面，放一个“删除按钮”，也就是跟“增加用户”按钮并排着放。勾选若干记录，点击“删除”，即完成批量清除。 增加用户界面和修改用户界面的功能重叠问题     我一般是这样的，增加用户的界面只让输入一两个最核心的字段，增加后跳转到修改用户界面，再输入更多明细信息 界面之间应该如何跳转？    1.列表中批量删除后，仍回到列表界面。    2.用户增加后，比较土的做法是回到列表界面，如果有条件的话，不是回到列表的第一页，而是回到新用户所在的页，这很麻烦的。还有一种做法是立即跳到该用户的明细页面或修改页面。个人倾向于 进入一个 “增加成功”的提示页面，这样可以明确地提示一上。而且这个页面里还要提供三个按钮：    “用户明细查看/修改” — 好奇心    “返回用户列表”  — 只加一个用户   “继续新增用户”   — 今天上午要连加20个用户    3.用户修改成功后，比较土的做法也是回到列表界面，而且也要考虑分页问题。个人倾行于修改后跳到明细界面（当然也可以转到 修改界面 ），同时用红字提示“修改成功”。 …

数据项 增、删、改、查的界面设计 — 经验 Read More »

尤其是两个系统进行数据交互时，要注意这种问题 1.如果一条数据为空，是彻底给空，还是给一个只含主键的空记录，还是给一条错误信息？ 2.如果一个容器内的数据都空了，是彻底给空，还是给空容器？

这个真要在做之前考虑周全，因为“用户”跟系统中很多其他资源都是挂勾的。如果一开始没做好，后来做起来就麻烦了 必须要考虑以下问题： 1.有没有guest用户？ 此guest和彼guest是否当作同一个人？ 对guest的登录点怎么控制？ 2.有没有admin,test等系统专有用户？ 这种用户在参与业务时该怎么对待？ 3.在真实用户里，除了张三、李四，有没有“综合管理员”这种虚拟用户？ 她在参与业务时该怎么对待？

待补充 0.交易日志 1.用户操作日志 2.报文日志 3.记录出错信息的系统日志

    以权限配置为例，在用户、角色、权利 三个实体中，角色和权利其实都应该写死，管理员只需配置用户和角色的关系就可以了。    否则：      1. 管理员直接配置业务逻辑，增加业务风险。管理员直接配置了角色和权利，相当于直接干预了业务逻辑，这给用户带来灵活性，但也带来了比较大的风险 —- 管理员配错权限怎么办?  比如管理员把“系统管理员”这一角色的管理权利给取消了，那怎么办？      2. 这给代码组织、程序发布也带来了麻烦。由于配置的东西太多，配置项可能写在SQL语句文件中，或者写在XML配置文件中，当权限规则发生微调时，这些文件也会发生微调，部署到生产系统后又要进行微调，经验证明，这很容易出错，因为XML和SQL的语法语义检查没有编译器来保证；而且，比起直接复制JAVA CLASS文件，部署XML和SQL的烦恼指数也高很多

人都是懒的 让用户少动一下老鼠 他会很感激你 的