项目代码杂谈
项目现况
半路加入团队,在旧项目上进行升级改造。net core 版本的 wpf 上位机项目。界面部分:window 2 个。usercontrol 大概14个,分了2个界面库(A与B,其中B是A的重点业务) + 1个界面帮助类库。
业务处理流程:xxxViewModel -> xxService -> xxRepository -> xxx实际处理。
配置数据存取流程:xx实际处理中注入数据处理接口 IDataContext。然后搞个实现类进行 xml 文件读写。
个人想法
业务流程中 "ViewModel -> Service -> Repository -> 实际处理" 这一条线我只保留头尾。实际项目中的 Service 与 Repository 层只是简单的传递数据,并没有做额外的业务处理或者数据转换。
这种仿 DDD 的写法在以前搞 web 的时候经常看到,cs 端我还是第一次看见。
"配置数据存取" 这一条线换了我只会直接在 xx实际处理中直接读写 xml 文件。配置数据要么存入本地文件xml或json,要么存入数据库。如果存入数据库,那么现有的 IDataContext 完全不能用;如果换成 json,那么 Json.NET 也能够很好的处理。
界面类库我觉得应该三合一,2个界面 + 14个用户空间放一个类库中并不多。现在类库B中还要定义事件,触发后再传递给类库A。帮助类库就创建 Converter,Helper 文件夹存放Helper类即可。
好的项目代码应该是可读性,封装性,可变性三者找到一个平衡点。
可读性是第一位。项目除非生命周期完结,不然日常的bug排查,新需求都离不开跟代码打交道。
封装性是第二位。合适的封装可以提升可读性,而且方便单元测试。无意义的封装就是简单问题复杂化,有问题解决问题,没有问题创造问题再解决。
可变性最后考虑。未来的需求谁也说不准。