协议缓冲区和OO设计 [英] Protocol buffer and OO design

问题描述

我正在使用协议缓冲区作为客户端-服务器体系结构中的有线数据格式.域对象(Java Bean)将经历以下生命周期.

I'm using protocol buffer as a wire data-format in a client-server architecture. Domain objects (java beans) will go through following life-cycle.

1. 用于客户端业务逻辑
2. 已转换为protobuf格式
3. 已传输到服务器
4. 转换回域对象
5. 用于服务器端业务逻辑

PropBuf文档中的

协议缓冲区和OO设计" 部分建议将生成的类包装在适当的域模型中

"Protocol Buffers and O-O Design" section in ProtoBuf documentation recommends wrapping generated class inside proper domain model.

我想找出最好的方法.

例如我有一个简单的原型定义.

For e.g. I have a simple proto definition.

package customer;

option java_package = "com.example";
option java_outer_classname = "CustomerProtos";

message Customer {
    required string name = 1;
    optional string address = 2;
}

这是定义域模型的方式.如您所见，数据完全存储在原型构建器对象中.

This is how domain model is defined. As you can see, the data is completely stored in proto builder object.

package com.example;

public class CustomerModel
{
    private CustomerProtos.Customer.Builder builder = CustomerProtos.Customer.newBuilder();

    public String getName()
    {
        return builder.getName();
    }

    public void setName(String name)
    {
        builder.setName(name);
    }

    public String getAddress()
    {
        return builder.getAddress();
    }

    public void setAddress(String address)
    {
        builder.setAddress(address);
    }

    public byte[] serialize()
    {
        return builder.build().toByteArray();
    }

}

这是一个好习惯吗?因为这些对象已在生命周期的所有阶段中使用，但我们只需要在客户端-服务器传输阶段使用protocolbuf格式.

Is this a good practice? because these objects are used in all phases of life-cycle, but we only requires protocolbuf format at client-server transmission phase.

特别是在原型定义复杂且嵌套的情况下，访问原型生成器类的getter/setter方法时是否存在任何性能问题?

Is there any performance issue when accessing proto builder class getter/setter methods specially when proto definition is complex and nested?

推荐答案

我对协议缓冲区没有任何经验，但我不建议实现为特定序列化/传输框架量身定制的域对象.您将来可能会后悔.

I have no experience with protocol buffers, but I would not recommend implementing your domain objects tailored to a specific serialization/transfer framework. You might regret that in the future.

软件应用程序的域对象和逻辑应与特定的实现问题(在您的情况下为序列化/传输)尽可能独立，因为您希望您的域易于理解并且将来可重用/可维护.

The domain objects and logic of a software application should be as independent as possible from specific implementation issues (in your case serialization/transfer), because you want your domain to be easy to understand and be reusable/maintainable in the future.

如果要定义与序列化/传输无关的域对象，则有两个选择:

If you want to define your domain objects independent of serialization/transfer, you have two options:

1. 在序列化/传输之前，您将信息复制到协议 缓冲特定对象并将其发送到您的服务器.那里你 将不得不将信息复制回您的域对象.
2. 使用非协议序列化库，例如 Kryo 或 ProtoStuff 直接将您的域对象转移到 服务器.

1. Before serialization/transfer, you copy the information to protocol buffers specific objects and send them to your server. There you would have to copy the information back to your domain objects.
2. Use a non-protocol serialization library like Kryo or ProtoStuff to directly transfer your domain objects to the server.

选项1的缺点是您的域被定义了两次(就修改而言是不希望的)和信息的复制(这会产生易于出错且不可维护的代码).

The disadvantages of option 1 are that your domain is defined two times (which is undesirable with respect to modifications) and the copying of information (which produces error-prone and non maintainable code).

选项2的缺点是您会丢失模式演变(尽管ProtoStuff显然支持 )，然后完整的(可能很大的)对象图被序列化并传输.尽管您可以在序列化/传输之前修剪对象图(手动或使用 JGT )修剪.

The disadvantages of option 2 are that you lose schema evolution (although ProtoStuff apparently supports it) and the complete (potentially large) object graph is serialized and transferred. Although you could prune the object graph (manually or with JGT) before serialization/transfer.

这篇关于协议缓冲区和OO设计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！