Chen Jian

要注意是否存在精确的一对一关系 假设两个系统分别为系统A和系统B 1.A中的某个用户在B中一定有吗？ 2.A中的用户Jude在B中也叫Jude吗？ 会不会冒用？ 3.A中的用户Jude在B中仅对应一个用户吗？ 会不会对应多个？

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

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

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

1.包含即匹配。 如果搜索 abc ，则 "hi,abc,you are a fool" 应该被选中 2.大小写不敏感。搜索abc，则“ABC”也应中标 3.一般要支持多关键字，关键字之间一般用空格分隔

    一个列表可能是       1.一个集合，元素不会重复       2.一个数组，元素可能重复       3.一个字典，名不会重复，但值会重复

    从汉语语法或者英语语法上说，“烹调工作”都是一个名词。但从语义上说，它其实代表着一个动作(cook)，因此它是一个“动明词”。 既然它是一个动作，那么在建模时就应该把它拆散，因为拆散了可以减少两部分的耦合，提高某个部分的可重用性         Cooking =  " Do something"  according to a " recipe" 在系统设计时    1. Cooking 和 Recipe 应该独立建模    2. Cooking中有时间、地点、厨师等属性    3. Recipe中则有原料、佐料、步骤等属性    4. Cooking 和 Recipe 是 多对一 关联关系，即同一个菜谱可以被多次使用。 如果我们一开始没有把它拆散，只做一个Cooking类，把原料、佐料也当作它的属性，那么 Recipe 就没办法重用。

    我们在做比较时，潜意识里可能倾向于把一切比较关系 都化成 大小关系， 比如 长短 就是长度大/长度小，额度高低 就是 金额大/金额小， 出生日期远近就是 年月日大/年月日小—–等等！日期远代表的年月日小，日期近代表年月日大，别搞反了！

要考虑“月”的认定办法，以及边界情况 要确定采用哪种算法： 1.直接用天数来算。 比如90天就算3个月 2.对月份进行加减，而日份不变。比如 2月1日到3月1日就是一个月，虽然这个月只有28/29天。如果用这种算法，还要注意月末日期溢出的问题，比如3月31日 的下一个月是 4月30日，还是5月1日？(p.s.采用java.util.Calendar API可以保证不会溢出，3月31日 的下一个月就是 4月30日) 还要注意的问题是：边界情况。   如6月2日到7月1日是否满一月，6月2日到7月2日是否满一月

而且如果写在数据库里，可以通过友好的UI界面直接进行修改