请原谅我使用了这样一个“直白”的标题,因为我实在想不到更好的描述方法。或许,是因为临近年底的“996”式冲刺,让许久没有读完一本书的我,第一次感受到输出时的闭塞。是时候为自己的知识体系补充新鲜血液啦,而不是输给那些“无聊”的流程和关系。说这句话的缘由,是想到《Unnatural》中的法医三澄美琴,一个视非正常死亡为敌人的女法医。而对程序员来说,真正的敌人则是难以解决Bug和问题。可更多的时间,我们其实是在为流程和关系方面的事情消耗精力。

我越来越发现,人类所面对的绝大多数问题,都并非是寻求一个最优解,而是在于平衡和牵制。人类总是不可避免地堕入熵增的圈套,伴随着流程产生的除了规范还有复杂度。每当人们试图为这种复杂度找一种友好的说辞的时候,我终于意识到,有的人不愿意去寻找问题的本质,它们需要的就只是一种友好的说辞,仿佛只要有了这种说辞,问题就能自动解决一样。我想,我大概知道这段时间感到焦灼的原因了,因为这样的事情在工作中基本是常态。人类每天面对的事情,无外乎两种:”明知不可为而为之”和”什么都想兼顾的美好理想”。

我今天想说的是,一个业务中遇到的单位转换的问题,我们平时在存储货物的重量时,默认都是以千克作为单位来存储的,直到我们对接了一家以大宗商品交易作为主要业务的客户,对方要求我们在界面上统一用吨来展示数据,因为这样更符合客户方的使用习惯。按理说,这是一个非常简单的需求,是不需要用一篇博客来说这件事情的,可我觉得这是个有意思的话题,还是想和大家一起来聊聊相关方案的思路。带着问题,我首先拜访了Cather Wong大佬,大佬微微一笑,表示在视图层上加个字段就可以了嘛。的确,这是最简单的做法,大概是下面这个样子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class OrderInfoQueryDTO
{
/// <summary>
/// 以千克为单位的净重
/// </summary>
public decimal? NET_WEIGHT { get; set; }

/// <summary>
/// 以吨为单位的净重
/// </summary>
public decimal? NET_WEIGHT_WITH_TON
{
get { return NET_WEIGHT / 1000; }
}
}

我不甘心地追问,客户要在原来的字段上显示这个数值啊,这样能行吗?大佬稍作沉思,随即问道:“你们公司的项目就算做不到DDD,AutoMapper这种实体间映射转换的东西总有吧!”。我连忙接话道:“这个自然是有的”。其实我心里想的是,总算有点符合我的心理预期啦,这样的方案还像个大佬的样子。按照大佬的提示,使用AutoMapper来做单位的转换,应该是下面这样:

1
2
3
4
var config = new MapperConfiguration(cfg => {
cfg.CreateMap<order_info, OrderInfoQueryDTO>()
.ForMember(d => d.NET_WEIGHT, opt => opt.MapFrom(x => x.NET_WEIGHT/1000));
});

这样看起来是比加字段要好一点,可实际项目中,我们往往会把单位作为一种配置持久化到数据库中,以我们公司为例,我们实际上是支持千克和吨两种单位混合使用的,不过在表头汇总的时候,为了统一到一起,所以使用了千克作为单位。这样就引申出一个新问题,假如我在数据库里存了多行明细的重量,当需要在表头展示汇总以后的总重量,那么,这个总重量到底是汇总好存在数据库里,还是展示的时候交由调用方Sum()呢?

我个人倾向于第二种,因为它能有效避免表头和明细行数据不一致的问题,当然缺点是给了调用方一定的计算压力。我们项目中采用的第一种方案,我印象非常深刻,在计算件数、重量和体积的时候,必须要等所有明细行都计算完以后,再通过调用Sum()方法给表头赋值,实际上这个表头字段,完全可以通过只读属性的方式取值啊,更何况我们还使用了外键,表头实体本身就引用了明细表实体,因为有外键的存在,序列化表头实体的时候会出现循环引用,对此,我想说,干得漂亮!

通过AutoMapper中的ForMember扩展方法,可以实现我们这里这个功能。可考虑到要在AutoMapper里引入权限啊、角色啊这些东西,AutoMapper作为实体映射的纯粹性就被彻底破坏了。为此,我们考虑使用AutoMapper中提供的Value ConvertersType Converters。关于这两者的区别,大家可以参考官方文档中的描述。此时,我们可以通过下面的方式使用这些“转换器”:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
var config = new MapperConfiguration(cfg => {
cfg.CreateMap<order_info,OrderInfoQueryDTO>()
.ForMember(d => d.NET_WEIGHT, opt => opt.ConvertUsing<WeightValueConverter,decimal?>());
});

var mapper = config.CreateMapper();
var orderInfo = new order_info() {
ORDER_ID = Guid.NewGuid().ToString("N"),
NET_WEIGHT = 1245.78M,
CREATED_DATE = DateTime.Now,
CREATED_BY = "灵犀一指陆小凤"
};

var orderInfoQueryDTO = mapper.Map<order_info,OrderInfoQueryDTO>(orderInfo);

而对于WeightValueConverter这个类而言,它实现了IValueConverter接口:

1
2
3
4
5
6
7
8
9
10
 public class WeightValueConverter : IValueConverter<decimal?, decimal?> 
{
public decimal? Convert (decimal? sourceMember, ResolutionContext context)
{
//TODO:可以查数据库或者是由规则决定,是否转换以及如何转换
if (!sourceMember.HasValue)
return null;
return sourceMember.Value / 1000;
}
}

现在,虽然代码还是这个代码,可至少我们不用在MapFrom里写太重的业务逻辑了,而且这个转换器是可以复用的。显然,我们的系统中不会只有订单模块会涉及到重量、体积的转换。此时,我们可以考虑使用ITypeConverter接口,遗憾地是,这个接口在实现的时候就必须指定源类型和目标类型,这样离我们设想地全局转换器实际上是有一点差距的。例如,我们有时候希望源类型中Null值不会覆盖到目标类型,最常见的情况是,从一个EditDTO转化为数据库实体对象并更新数据库。为了解决这个问题,AutoMapper下面的做法就非常棒:

1
cfg.ForAllMaps((a, b) => b.ForAllMembers(opt => opt.Condition((src, dest, sourceMember) => sourceMember != null)));

可对于我们这里这个场景,显然,我们必须要提供一部分类型信息,我们几乎很难给所有的Map增加一个通用的类型转换器。我最终还是通过反射解决了这个问题,即在使用AutoMapper前,从数据库查出数据后,首先要做的第一件事情就是对数值进行转换:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
var userSetting = UserContext.GetLoginUser().UserSettng;
var formatSetting = userSetting.FormatSetting;

//当默认重量单位为KG时不做任何处理
if (formatSetting.DefaultWeightUom == WeightUnit.KG)
return;


var properties = typeof(TDestination).GetProperties()
.Where(p => p.Name.EndsWith("WEIGHT") || p.Name.EndsWith("Weight"));
if (properties == null || !properties.Any())
return;

foreach(var item in destList)
{
//转化结果为吨
foreach(var property in properties)
{
var weightValue = property.GetValue(item, null);
if(property.PropertyType == typeof(decimal))
{
property.SetValue(item, (decimal)weightValue / 1000);
}
else if(property.PropertyType == typeof(Nullable<decimal>))
{
if (weightValue != null)
property.SetValue(item, (decimal)weightValue / 1000);
}
else if(property.PropertyType == typeof(string))
{
if (!string.IsNullOrEmpty(weightValue.ToString()))
property.SetValue(item, decimal.Parse(weightValue.ToString()) / 1000);
}
}
}
}

不得不说,这段代码相当无聊,可无论多么无聊的功能,只要客户觉得好就给积极地去做,对吧!其实,说到底,这是我们在设计数据库表结构时遗留的一个问题。假如我们在存储的时候就存储为吨,问题还不会有什么不一样呢?实际上,它还是会有问题,因为你不得不去设计一个单位转换表,类似下面这样的:

原始单位 目标单位 进率
Kg T 1/1000
T Kg 1000
g Kg 1/1000
Kg g 1000

我们目前设计的表结构中实际上是有重量单位的,不同的是,我们以千克为单位存储的量,数据库中对应的WEIGHT_UOM存储的是1,而以吨为单位存储的量,数据库中对应的WEIGHT_UOM存储的是1000。所以,理论上真实的重量都应该是数据库中存储的量 X WEIGHT_UOM。这样看起来是没有问题的,可当你结合今天这篇博客的背景来看是,就会发现一个问题,所有的数值在展示的时候都必须要知道,数据库里存储的数值的原始单位是什么,而使用者希望在界面上看到的数值的单位又是什么。

不单单如此,当用户通过界面查询的时候,一个简单的数字便不等再用简单地使用像大于、小于、等于、不等于这样的查询条件,因为现在每个量都带着单位,你必须明确得知道,用户认为的单位是什么,而数据库里对应的单位又是什么?这样听起来貌似还是统一使用一种单位比较好,正因为如此,博主可以在查询前把吨转化为千克,而在查询后则可以把千克转换为吨。

人类世界总是存在着这些奇奇怪怪的规则,不同的小数位精度要求,不同的货币金额展示方式,不同的日期格式显示要求,就在我写下这篇博客的时候,产品同事反馈我千克转成吨展示以后,应该至少保留三位小数,否则会让人觉得数字会丢失了精度。我还能说什么呢?联想到最近软通因为加班而猝死的同行,我大概只能说一句:恭喜你,还请节哀顺变,欢迎来到无法随心所欲的爱与欲望的世界!作为拖延症中晚期的博主,努力写完每月一篇的博客,抽空读读书、看看电影,这已然是种简单的幸福了呢!好了,这篇博客就先写到这里!