我应该使用POJO还是JSONObject进行REST调用 [英] Shall I use POJO or JSONObject for REST calls
问题描述
最近，我偶然发现了一个情况，即我的新团队大量使用JsonObject进行剩余数据交换.他们的观点是，在使用pojo时，我们与其余服务紧密绑定，而jsonObject提供了自由.此外，它还避免了不必要的数据序列化，同时大大减少了类数.
Recently I have stumbled upon a situation where my new team is heavily using JsonObject for doing rest data interchange. Their view is while using pojo we are binding tightly with the rest service, while jsonObject gives freedom. Also it saves from unnecessary data serialisation at the same time reducing number of classes heavily.
我遇到一些要点:
- Pojo为数据赋予了更多含义，我们正在保存具有正确数据类型的数据.
- 如果只需要json的10个字段中的2个字段，则可以使用
@JsonIgnore反序列化为2个字段类
- Pojo gives more meaning to data and we are holding data with correct data type.
- If we need only 2 fields of 10 fields of json, we can deserialize to 2 fields class with
@JsonIgnore
我不知道反序列化的确切成本，但是我觉得它应该没有太大的区别.
I don't know exactly on the cost of deserialisation, but somehow I have a feeling it shouldn't be much difference.
有人可以帮助我理解应该采取哪种观点吗?
Can someone help me understand which perspective is way to go ?
请提供使用POJO和JSONObject的利弊.
Please provide some pros and cons of using POJO and JSONObject.
谢谢
推荐答案
我发现拥有pojos具有以下优点
I see the following advantages in having pojos
1)可读性-您将不会真正了解复杂json的结构.编写一个简单的get将需要知道json的结构.请参考我的文章的基于JSON对象的POJO"部分-> https://medium.com/tech-tablet/programming-went-wrong-oops-38d83058885
1) Readability - You will not really know the structure of a complex json. writing a simple get will require one to know the structure of the json. Please refer to the "POJOs over JSON Objects" section of my article here -> https://medium.com/tech-tablet/programming-went-wrong-oops-38d83058885
2)提供类型检查-我们可以轻松地将Cat分配给Dog，甚至在运行时甚至都不知道.
2) Offers Type Checks - We could easily assign a Cat to a Dog and not even know about it till runtime.
3)通过Composition&感觉更面向对象.封装-使用POJO很容易理解设计师的观点.是具有HAS-A车轮的IS-A车辆的汽车.
3) Feels more object-oriented with Composition & encapsulation - It's easy to understand the designer's perspective with a POJO. A Car which IS-A Vehicle that HAS-A Wheel.
4)您可以选择要反序列化的内容，然后仅将其保留在内存中-当使用JSON对象反序列化刚刚通过网络接收到的对象时，无法选择要反序列化和存储的内容进入记忆.如果您有一个1 MB大小的对象，其中只有200字节是您的有效负载，那么如果不使用POJO，我们最终将整个1 MB对象保存在内存中.
4) You could choose what you wanna deserialize and keep only that in memory - When deserializing the object that we have just received over the network, with a JSON Object, there is no way to choose what has to be deserialized and stored into memory. If you have an object of 1 MB size where only 200 Bytes is your payload, we will end up holding the entire 1 MB object in memory if we don't use POJOs.
5)允许使用collection并以清晰的方式对其进行流操作-JsonNode中不存在对流操作的本机支持.我们将需要使用可以避免的StreamStupport对象.
5) Allows collection to be used and stream operations on them in a legible way - There is no native support for stream operations in a JsonNode. We will need to use a StreamStupport object which could be avoided.
6)允许跨框架引用.通过一些注释，您可以选择将特定字段映射到数据库客户端-当您将ORM框架用于数据库时，很容易注释实体并将其映射到数据库模式.
6) Allows cross framework referencing. With a few annotations, you can choose to map specific fields to a database client - When you use an ORM framework for you database, it's easy to annotate and map entities to the database schema.
7)自然支持设计模式
7) Naturally supports design patterns
8)最小化非本机依赖性-为什么必须使用本机Java本身没有的JsonNode或等效项?尤其是如果它具有上述缺点.
8) Minimalizing non-native dependencies - Why do you have to use a JsonNode or equivalent that does not come by itself in native Java? Especially if it has the above disadvantages.
如果您担心像pojo一样的仪式(例如有吸气剂，二传手等)，请查看龙目岛".该库将帮助您以简洁的方式创建pojos，并仍然获得上述好处.
If you are concerned about the rituals that come with a pojo like having getters, setters etc, take a look at "Lombok". This library will help you create your pojos in a concise way and still reap the above benefits.
另一方面，如果您要处理的是难以更改的旧API，该API会以动态变化的响应进行响应，那么JsonNode是一个快速的候选人.
On the other hand if you are are dealing with a hard to change legacy API that responds with a dynamically changing response, JsonNode is a quick win candidate.
这篇关于我应该使用POJO还是JSONObject进行REST调用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
