架构,改善程序复用性的设计~第三讲 实现一种功能的代码只能出现在一处(续)

简介:

在写完架构,改善程序复用性的设计~第三讲 实现一种功能的代码只能出现在一处 , 这篇文章后,得到了园友的反馈,说这种简单的业务逻辑还可以,但业务比较复杂时,根据就没法用这种方法。

针对这个问题,我觉得有必要再写一个续集了,呵呵!

上回说的主要核心内容是将公用的部分从一个方法中提取出来,生成一个新的方法,这个重构中叫做“提取到方法”
,另外一个核心内容就是方法的”单一职责“,即一个方法干一件事,将出现复杂事件时,将多个方法进行组合调用即可

这回主要说一个重构中的提取,其实不仅方法可以被提取,类,及整个项目也可以被提取,只要他们有被提取的必要!
一个例子:对于一个数据实体操作的基类,它包括了其它所有实体类共有的属性(DB)和方法(SubmitChanges),这可以理解了”提取到类“,当然这也是类的继承及面向对象的一个例子。

 1      /// <summary>
 2     /// LINQ数据库操作基类
 3     /// </summary>
 4     public abstract class RepositoryBase
 5     {
 6         public RepositoryBase(DataContext db)
 7         {
 8             DB = db;
 9         }
10        protected System.Data.Linq.DataContext DB { get; private set; }
11 
12         #region DBContext SubmitChanges
13         /// <summary>
14         /// XXB默认提交【重写时候可能需要写入自定义的类似约束的逻辑】
15         /// </summary>
16         protected virtual void SubmitChanges()
17         {
18             ChangeSet cSet = DB.GetChangeSet();
19             if (cSet.Inserts.Count > 0
20                 || cSet.Updates.Count > 0
21                 || cSet.Deletes.Count > 0)
22             {
23                 try
24                 {
25                     DB.SubmitChanges(System.Data.Linq.ConflictMode.ContinueOnConflict);
26                 }
27                 catch (System.Data.Linq.ChangeConflictException ex)
28                 {
29                     foreach (System.Data.Linq.ObjectChangeConflict occ in DB.ChangeConflicts)
30                     {
31                         // 使用当前数据库中的值,覆盖Linq缓存中实体对象的值  
32                         occ.Resolve(System.Data.Linq.RefreshMode.OverwriteCurrentValues);
33                         // 使用Linq缓存中实体对象的值,覆盖当前数据库中的值  
34                         occ.Resolve(System.Data.Linq.RefreshMode.KeepCurrentValues);
35                         // 只更新实体对象中改变的字段的值,其他的保留不变  
36                         occ.Resolve(System.Data.Linq.RefreshMode.KeepChanges);
37                     }
38                     DB.SubmitChanges();
39                 }
40             }
41         }
42 
43         #endregion
44      }

还有一种更大程序上的提取,即”提取到项目“,就是说,它的整个项目都是其它项目公用的部分,所有把整个项目抽象出来

Entity.Commons这个项目是对所有解决方案的所有实体层进行的抽象,它里面有对实体的分页,实体参数组织,实体消息返回及实体统一验证等功能,都在Entity.Commons里实现

EntityBase.cs代码如下:

View Code

通过这篇文章,我们知道了,对于代码重构,不仅仅只对于方法而言,对于重构,也不仅仅只对一个项目而言,它可能是项目与项目之间的重构。

本文转自博客园张占岭(仓储大叔)的博客,原文链接:架构,改善程序复用性的设计~第三讲 实现一种功能的代码只能出现在一处(续),如需转载请自行联系原博主。

目录
相关文章
|
2月前
|
运维 监控 数据管理
Apollo与微服务架构:构建可扩展的应用程序
Apollo与微服务架构:构建可扩展的应用程序
|
4月前
|
存储 测试技术 数据库
谈谈代码:降低复杂度,从放弃三层架构到DDD入门
最近我发现团队某项目的复杂度越来越高(典型的三层架构),具体表现为: - 代码可读性较差:各个服务之间调用复杂,流程不清晰 - 修改某服务业务代码导致大量无关服务的测试用例失败,单个功能开发者很难迅速定位相关问题 - 测试用例特别难编写,需要mock大量数据来拉起整块服务
102 4
谈谈代码:降低复杂度,从放弃三层架构到DDD入门
|
26天前
|
NoSQL Java Redis
【分布式技术专题】「分布式技术架构」手把手教你如何开发一个属于自己的分布式锁的功能组件(二)
【分布式技术专题】「分布式技术架构」手把手教你如何开发一个属于自己的分布式锁的功能组件
15 0
|
2月前
|
机器学习/深度学习 测试技术 Ruby
YOLOv5改进 | 主干篇 | 反向残差块网络EMO一种轻量级的CNN架构(附完整代码 + 修改教程)
YOLOv5改进 | 主干篇 | 反向残差块网络EMO一种轻量级的CNN架构(附完整代码 + 修改教程)
128 2
|
30天前
|
程序员 Python
类的设计奥秘:从代码到架构的科普全解
类的设计奥秘:从代码到架构的科普全解
13 2
|
1月前
|
消息中间件 并行计算 网络协议
探秘高效Linux C/C++项目架构:让进程、线程和通信方式助力你的代码飞跃
探秘高效Linux C/C++项目架构:让进程、线程和通信方式助力你的代码飞跃
34 0
|
1月前
|
存储 设计模式 前端开发
请解释 Web 应用程序的 MVC(模型-视图-控制器)架构。
【2月更文挑战第26天】【2月更文挑战第89篇】请解释 Web 应用程序的 MVC(模型-视图-控制器)架构。
|
1月前
|
SQL 存储 数据管理
数据库系统架构与DBMS功能探微:现代信息时代数据管理的关键
数据库系统架构与DBMS功能探微:现代信息时代数据管理的关键
36 1
|
2月前
|
设计模式 微服务
从代码到架构,我的技术成长之路
【2月更文挑战第5天】技术是一门不断进步的艺术,我在不断的实践中,通过学习和思考,逐渐领悟到了代码、架构等方面的知识和技能。在这个过程中,我发现技术并不仅仅是一种工具,更是一种思维方式和生活态度。本文将分享我的技术成长历程和所获得的思考。
27 2
|
2月前
MFC应用程序对话框架构
MFC应用程序对话框架构
13 0