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

原创

wx60f7f54847950 2021-07-23 15:21:15 博主文章分类：管理，架构，设计 ©著作权

©著作权归作者所有：来自51CTO博客作者wx60f7f54847950的原创作品，请联系作者获取转载授权，否则将追究法律责任

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

一。权限策略的问题。模型：公文流转，如果 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了。