整理在架构业务层所要考虑的非技术问题

整理在架构业务层所要考虑的非技术问题。

一。权限策略的问题。模型： 公文流转 ， 如果 A 发给 B  ， B 转发给 C 。 通用权限 ： Edit  ， Look ， None 。 专用处理权限：是否允许编辑附件，是否允许删除等。

最大化权限策略：那么 A 具有 Look ， B 具有Edit ， C具有 Edit 。为了给用户更大的权限， 这是我选择的方式，但是，它还要在任何一方打开时及时的锁住该公文，其它人不可改。略显复杂。

最小化权限策略：那么 A 具有 None，  B 具有None（或 Look ） ， C 具有 Edit 。它与最大化权限相排斥。给客户权限比较小。

通用权限策略：在 系统层处理通用权限 ， 根据 最大化或最小化权限返回 Edit ，Look，  或None 。
专用权限处理：在 各自的页面 处理 通用权限之下的专用权限， 如通用权限返回我只能看， 但没有说我能看哪些部分。 或通用权限返回我可以 Edit ， 但没有说，我能改哪些部分。  通用＋专用， 也是我选择的方式。

二。是基于数据，还是基于业务。模型，公文流转的四个状态： Editing ， Approving ， Approved  ，Done 。

比如：如果没有上报，则没有数据，则不显示TextBox 控件 的逻辑。是依赖于 上报状态，还是依赖于 数据是否存在？

通常情况下，依赖状态，性能会高一些，但是，业务是可变的， 当有一天说， 如果没有上报，也可能有值 ，还是要显示的。

通用处理是， 如果有值，则显示，没有值，则不显示。 这样， 对业务的依赖会减少，但是性能稍稍差一些。 这是我选择的方式。

三。数据库枚举存储方式，是用 Int ，还是用 String 。为了和程序对应，为了和页面参数对应， 数据库的字段枚举可以定义给 Enum 。 但 Enum 即可以存储为 String ， 又可以存储为 Int ， 为了更好的可读性，应该存成 String ， 但是为了更高的性能， 应该存为 Int 。 我采用的是存储为 String ， 实践表示，存储为 String ， 在调试和修改时， 会带来很大的便利性。

四。单表视图。 即如果一个表结构很复杂， 字段很多， 为了给开发人员分析和开发方便，给他们从原表中抽取一部分字段，定义成 单表视图。

五。在架构设计上，从技术着手，而不是从业务着手。

即不应该做这样的功能。传 Select 的列，传 Where 条件 ， 则返回 DataSet 之类。增加复杂度。而且，里面有隐含的依赖。写成通用的 SQLHelper 是不错的。

六， 坚绝执行， 不重复开发。统一风格的简单处理。 像选人， 上传等通用功能，做一处就OK了。