我正在创建一个WCF服务，该服务公开了一个对象图，当服务启动并运行时，该对象图的大小会有所增加。在玩一些测试数据（85k）时，实际上可以预期的更小，我达到默认的65k消息大小限制。在网上快速浏览一下就可以很简单地在配置中扩展它。
当我创建服务和使用它的客户端时，我想知道在发送数据之前压缩数据是否有附加价值。运行一个简短的测试后，测试数据缩小到7k左右，所以这看起来有助于通过网络发送消息的时间，并增加我可以发送的数据量。
服务在第一次呼叫之前预先准备数据，因此压缩时每次呼叫都没有初始开销。
为了可扩展性，尝试优化性能，或者在不需要的情况下增加复杂性，这是一个好主意吗？
答案 0 :(得分：1)
只要你没有使用模糊的压缩格式，我认为你没有添加任何明显的复杂性。一行或两行代码。也许你可以在服务调用中添加一个参数，让客户选择压缩或未压缩的数据。
答案 1 :(得分：1)
通过阅读您的帖子，您似乎很容易实现此压缩。
如果您控制两侧，添加一层压缩/解压缩并不会增加一般情况下的复杂性，因为它可以从中获得大量带宽优势。
通过实施Interceptor或Decorator等某些模式，您可以采取哪些措施来降低复杂性。
答案 2 :(得分：0)
你们都可以更具体，我应该做些什么来加密和加密压缩和解密＆amp;两端成功解压缩数据？哪种压缩Algo最适合压缩大数据，缩短压缩和解压缩时间，压缩和解压缩小数据，有效地在客户端和服务器之间传输数据。
@decyclone：什么是拦截器或装饰器？请具体而明确。