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日随笔