浏览：97 时间：2024-04-10
EOS编码要注意哪些
一、描述
三层：Dao，Dso，Controller，cshtml和Entity
三层的关系是：
Dao服务于Dso，Dso服务于Controler，Controller服务于cshtml，不能跨层。Entity服务于Dao和Dso和Controller。
Dao和Dso可能给外界提供服务，比如渠道商二开、客户二开、实施部二开。外界就是非本EOS整个系统的研发。
二、功能描述。
Dao主要是数据访问。
Dso主要是一件完整的任务，可能调用dao做数据访问，可能调用工具类。
Controller主要是解析界面和给界面提供数据。
三、每层返回值
Dao的返回值不能用object，他是不明确的，可读性差，输入和输出一定要明确的对象类型。
Dso的返回值不能用object,他是不明确的，可读性差，输入和输出一定要明确的对象类型。
Controller的返回值允许object，当然尽可能不用object。
原则就是给别人调用的一定要可读性好，给自己用的尽量可读性好。
四、我怎么做到命名规范和符合代码规则？
Dao->dso->Controller是一个椭圆形，dao和控制器层代码小，逻辑层相对大，当然85%情况应该是这样，凡事不能一刀切。
控制器层每个方法里面的实现一定是逻辑简单，一看就懂，只是为了页面展示拼凑数据或者解释数据，而不要有逻辑在里面。
设计Dao时候，你考虑别人读起来是否容易，命名可以是技术性字眼，一般是数据库的单个和批量的增删改查。
设计Dso时候，要考虑意见完整的事写在一起，当然看复杂度可以拆分几个小的任务包。你也要考虑如果别人调用你读起来是否容易，命名要有业务字眼。
控制器层命名和实现要考虑能否为pc端服务，也能为手机端服务？Pc端界面和手机端不一致。
命名好坏影响别人调用理解。
位置摆放影响别人查找。
代码重用多，存活久，说明这段代码有效性高，说明作者有效性高，作者自然而然价值高。
函数归属哪个类、命名字眼都要考虑一下不仅仅你眼前用，别人用会感觉怎么样。按照我上面之处的方面考虑就可以了。
五、图形展示
六、Frame与业务子系统
Frame主要安放Setting平台相关与业务有关的代码，如果是第三方接口耦合度高，复方在里面，工具脱离业务不放在里面，这两个都可能将来不断替换，所以放在工具插件里面，不分版本，兼容所有版本。
Frame与业务子系统一样，可能有业务板存在，不同版本之间有差异，但是他们都可以调用最新的第三方接口和工具类。所以Frame也要保持小巧精悍。
一个架构中的模块各有分工，目的是解耦，复杂的分隔成简单的，一般来讲耦合度增大一倍，复杂度可能是指数增长。
2024-4-10日随笔