对象列表的封装方法
本文关键字:方法 封装 列表 对象 | 更新日期: 2023-09-27 18:16:05
我有一个类,看起来像这样:
public class MyModel{
public int TheId { get; set; }
public int ....
public string ....
}
我有另一个类,它接受几种类型的列表,包括MyModel,并在json中序列化列表。它有几个方法,每种类型的list对应一个方法。
public class ToJson{
public string MyModelToJson (List<MyModel> TheListOfMyModel) {
string ListOfMyModelInJson = "";
JavascriptSerializer TheSerializer = new ....
TheSerializer.RegisterConverters(....
ListOfMyModelInJson = TheSerializer.Serialize(TheListOfMyModel);
return ListOfMyModelInJson;
}
public string MyOtherModelToJson (List<MyOtherModel> TheListOfOtherModel) {....}
public string YetAnotherModelToJson (List<YetAnotherModelToJson> TheListOfYetAnotherModelToJson) {....}
}
我要做的是将序列化封装到MyModel中,就像这样:
public class MyModel{
public int TheId { get; set; }
public int ....
public string ....
public string MyModelToJson()
}
我如何将一个方法封装到一个对象中,以便它可以用于一个对象列表?
我想做一个foreach循环,但这会变得很混乱,因为在调用方法中,你必须操作列表中每个对象的json字符串并将它们连接起来。
让我知道在这种情况下应用的OO封装原则。
谢谢你的建议。
一种方法是将ToJson定义为接受泛型类型:
public class ToJson<T>{
public string MyModelToJson (List<T> TheListOfMyModel) {
string ListOfMyModelInJson = "";
JavascriptSerializer TheSerializer = new ....
TheSerializer.RegisterConverters(....
ListOfMyModelInJson = TheSerializer.Serialize(TheListOfMyModel);
return ListOfMyModelInJson;
}
}
扩展方法!
public static class JsonExtensions
{
public static string ToJson<T>(this List<T> list)
{
}
}
我不确定我是否理解你的问题,但我认为你想做的不是返回
String
,而是返回JsonObject
, JsonArray
或JsonPrimitive
:
public class MyModel {
public JsonObject myModelToJson() ... //this method implements the interface!
}
其中JsonObject
是一个代表json对象的类。
让这个类实现一个接口,其中约定返回值为JsonValue
。
然后,在ToJson
类中,返回JsonArray
:
public class ToJson
public JsonArray myModelToJson(List<things that can be json-ized> myList) ...
}
除非绝对需要,否则不要将对象/数组/原语序列化为String,并且让库来处理实际的序列化
这是一个令人困惑的答案。
我认为你应该这样做:
- 得到一个像样的json库。理想情况下,它应该有
JsonObject
s、JsonArray
s和JsonPrimitive
s,它们是JsonElement
的子类。我在java中使用过Google gson,但我不知道c#版本是什么。 - 创建一个接口,
JsonAble
与一个方法-toJson
-返回JsonElement
。 - 为所有相关类实现此接口 序列化
- 一个像样的json库应该有一个序列化方法——这样你就不必担心自己抛出字符串了
JsonAble
对象列表非常容易——它变成了JsonArray
。无论如何,我都不会删除这个类。你所说的是给你的模型增加额外的责任,显然是违背SRP启发式的。也就是说,您有一个类,其当前的职责是对数据建模,您将使它负责对数据建模,并使用它现在需要了解的各种服务类将其数据转换为某种形式。如果模型类封装了GUI概念,比如为GUI引发事件,那么它有不同的改变理由——如果通知GUI的模式改变了,如果转换为JSON的模式改变了。
如果是我,我会让模型从基类继承,或者定义Matt Fenwick提到的接口,并让你的ToJson类接受一批模型作为输入,处理它们,并返回结果。
我理解消除额外类的愿望,如果它是一个只涉及类的数据元素的简单转换,可能会提倡它,但是一旦您需要某种类型的服务类来完成操作,它似乎不适合模型对象,因为您现在无法在没有JavascriptSerializer的情况下对数据建模。如果你想对不序列化的数据建模,那就很尴尬了。
我能想到的最后一件事是,您可以基于'b'c'd 'f'g'h的建议进行构建,并将该方法移植到某些现有的服务上,从而消除类。如果在该服务上只有实现序列化的泛型方法,则可以消除单独的类,因为您不再需要为每个模型对象类型使用单独的方法。