最近完善自己的專案中,將很多原先的framework下的類別庫都轉為.net standard類別庫,服務自然也往.netCore上轉.因此,寫了一個WebApi做為服務來完善自己的類別庫程式.
在我的程式體系中中有一部分的方式是要客戶端傳送Sql到服務端,服務端回傳DataSet到客戶端進行處理,WCF的服務端運行了7,8年了都很穩定,打算將WebApi的服務也完善進去.
這里自然最重要的一步就是DataSet的序列化和反序列化.
關于DataSet的序列化與反序列化,自然是用到了我十來年一直用的XmlSerializer類來進行,沒有任何問題,沒想到這里在反序列化時竟然報錯,我都不敢相信自己的眼睛.
經過各種猜測,各種嘗試后,發現如果客戶端也用.NetCore,就不會報錯.加之現在這個序列化的方式過于老舊,打算用比較新的Newtonsoft.Json來進行DataSet的序列化與反序列化,而且還用到專門序列化與反序列化DataSet的方法
StringDataSet = JsonConvert.SerializeObject(ds, new Newtonsoft.Json.Converters.DataSetConverter());
DataSet ds1 = JsonConvert.DeserializeObject<DataSet>(StringDataSet, new Newtonsoft.Json.Converters.DataSetConverter());
我還專門看了看序列化之后的字串:
{"Table":[{"IP":"*.*.*.*","UUID":null,"key":"XYS.Lab.BLL.LoginDemo.GetUser","value":"select * from Users where loginname_str='{0}'","創建時間":"2020-04-07T14:44:28","修改時間":null,"ID":"68d26fac-ea54-4617-b5ea-c0777603df5c"}]}
我看到這個序列化后的字串后,心就涼了,這tm的序列化完事了連個列的型別都不標注,百分百反序列化后會有問題,型別肯定是轉換不對的.果不其然,雖然可以反序列化成DataSet,也有值,看著也對,但是往細里面看資料型別的時候,發現原本DataSet中的Guid型別,轉換完成后變成了string型別.這讓我很郁悶.
但是同時也給了我一個提示,是不是再用XmlSerializer序列化反序列化的時候,也是型別出了問題呢?
經過認真對比.NetCore下序列化的結果和.Net framework序列化后的結果發現了:
<xs:element name="UUID" msdata:DataType="System.Guid, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e" type="xs:string" minOccurs="0" /> <xs:element name="UUID" msdata:DataType="System.Guid, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" type="xs:string" minOccurs="0" />
問題就出在這里,在.NetCore里和.Net framework里 對于這種特殊型別的序列化,做了詳細的說明,連后面的DLL,版本號等詳細資訊都列出來了,所以自然轉換不過來.
當我把.NetCore序列化的結果里關于Guid型別的這個描述替換成了.Netframework下的之后,反序列化成功了,而且很完美.但是這里還有一個問題,到底有多少種型別在序列化的時候跟Guid一樣呢?我查了半天也沒查到.
所以這里陷入了兩難的境地.
用Newtonsoft.Json序列化實在是太粗了,反序列化后竟然有資料型別不一致的問題.
但是用XmlSerializer序列化又太tm的細致了,我可以替換一個Guid,但是不能保證所有的類似于Guid的型別都替換.
在此記錄也算是給各位一個提醒,少走彎路,目前我大致的想法是先用Newtonsoft.Json做序列化,真的后面出現型別不一致造成問題了,再處理吧.
Newtonsoft.Json做序列化因為型別果然出現了問題,之前的代碼在給dataset復制的時候,報錯了,型別不對,看來目前還要用XmlSerializer序列化加上專門的字串替換方式.
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/44847.html
標籤：C#