Questions tagged «serialization»

根据DDD，域逻辑不应被序列化，对象关系映射等技术问题所污染。 那么，如何在不通过getter和setter公开公开状态的情况下序列化或映射聚合状态？我已经看到了很多示例，例如存储库实现，但是实际上所有示例都依赖于实体上的公共访问器和用于映射的值对象。 我们可以使用反射来避免公共访问器，但是IMO这些域对象仍将隐式依赖于序列化问题。例如，在不调整序列化/映射配置的情况下，您无法重命名或删除私有字段。因此，您必须考虑序列化，而应将重点放在域逻辑上。 那么，要遵循的最佳妥协是什么？与公共访问器一起生活，但要避免将它们用于映射代码以外的其他用途？还是我只是想念一些明显的东西？ 我对序列化DDD域对象（由实体和值对象组成的聚合）的状态特别感兴趣。这与无状态服务在简单数据容器对象上运行的常规脚本或事务脚本场景中的序列化无关。

23 object-oriented  domain-driven-design  orm  serialization 

我们有可以提供XML或JSON（WCF）的REST Web服务。我在玩实现Protobufs的想法。为什么？ 优点 减轻服务器负载。 较小的邮件大小-较少的流量。 现在切换比现在容易。 缺点 需要实施 很难对消息进行故障排除/嗅探以进行调试。 我可以在服务器上启用GZip，而JSON将消耗尽可能多的流量 您对此有何建议和/或经验？

23 web-services  wcf  serialization 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 序列化用于Java的持久性。可以使用序列化持久化一些对象。但是，对于大量对象，ORM，数据库等可能会更好。似乎序列化仅对小型作业有用。可能是我错了。因此，请告诉我序列化比非序列化方法有什么优势？什么时候应该使用，什么时候应该避免使用？ 看到DZone文章“对象序列化是否有害”之后，这个问题浮现在我脑海。 以下是引起我疑问的内容： 如果您查看Java及其会话对象，则使用纯对象序列化。假设应用程序会话的寿命很短（最多几个小时），则对象序列化非常简单，得到了很好的支持，并内置在会话的Java概念中。但是，当数据持久性处于较长的时间段（可能是数天或数周）时，并且您不得不担心应用程序的新发行版时，序列化很快就会变成邪恶。正如任何优秀的Java开发人员所知道的那样，如果您打算序列化对象（即使在会话中），则需要一个真实的序列化ID（serialVersionUID），而不仅仅是1L，并且您需要实现Serializable接口。但是，大多数开发人员都不知道Java反序列化过程背后的实际规则。如果您的对象已更改，则不仅仅向对象添加简单字段，即使序列号未更改，Java也可能无法正确反序列化对象。突然，您无法再检索数据，这本质上是糟糕的。 现在，可能开发人员阅读此文章可能会说他们将永远不会编写有此问题的代码。可能是这样，但是您使用的库或公司不再雇用的其他开发人员呢？您能保证这个问题永远不会发生吗？保证的唯一方法是使用其他序列化方法。

20 java  serialization 

我正在评估基于Java的服务的Google协议缓冲区（但希望使用与语言无关的模式）。我有两个问题： 第一个是一个广泛的一般性问题： 我们看到人们使用什么模式？所述模式与类组织（例如，每个.proto文件，打包和分发的消息）和消息定义（例如，重复字段vs.重复封装字段*）等有关。 在Google Protobuf帮助页面和公共博客上，此类信息很少，而对于已建立的协议（例如XML）则有大量信息。 对于以下两种不同的模式，我也有特定的问题： 将消息表示为.proto文件，将它们打包为一个单独的jar，然后将其发送给服务的使用者-这基本上是我认为的默认方法。 这样做，但在每条消息周围包括手工包装器（不是子类！），这些消息实现了至少支持这两种方法的协定（T是包装器类，V是消息类（使用泛型，但为简化起见简化了语法） ： public V toProtobufMessage() { V.Builder builder = V.newBuilder(); for (Item item : getItemList()) { builder.addItem(item); } return builder.setAmountPayable(getAmountPayable()). setShippingAddress(getShippingAddress()). build(); } public static T fromProtobufMessage(V message_) { return new T(message_.getShippingAddress(), message_.getItemList(), message_.getAmountPayable()); } 我从（2）中看到的一个优点是，我可以隐藏由它引入的复杂性，V.newBuilder().addField().build()并在包装器中添加一些有意义的方法，例如isOpenForTrade()或isAddressInFreeDeliveryZone()等。我在（2）中看到的第二个优点是我的客户端处理了不可变的对象（可以在包装类中强制执行的事情）。 我在（2）中看到的一个缺点是我复制了代码，并且不得不将包装类与.proto文件进行同步。 有没有人对这两种方法有更好的技巧或进一步的批评？ *通过封装重复字段，我的意思是像这样的消息： message ItemList { repeated …

19 serialization  protobuf 

我目前处于C＃.NET应用程序的几个模型类的（重新）设计阶段。（模型与MVC中的M相同）。模型类已经具有大量精心设计的数据，行为和相互关系。我正在将模型从Python重写为C＃。 在旧的Python模型中，我认为我看到了疣。每个模型都知道如何进行序列化，而序列化逻辑与任何类的其余行为无关。例如，假设： Image类的.toJPG(String filePath) .fromJPG(String filePath)方法 ImageMetaData.toString()和.fromString(String serialized)方法的类。 您可以想象这些序列化方法与该类的其余部分之间是否没有凝聚力，但是只能保证该类知道足够的数据来对其自身进行序列化。 上课知道如何序列化和反序列化是一种常见的做法吗？还是我错过了通用模式？

16 c#  object-oriented  python  serialization 

为了更加清楚，这是一个简单的示例： class A implements Serializable { public B b; } class B implements Serializable { public A a; } A a = new A(); B b = new B(); a.b = b; b.a = a; 那么，如果我们将a和b对象序列化到文件中并从该文件反序列化，会发生什么呢？ 我以为我们得到4个对象，每个对象2个。相同的对象，但实例不同。 但是我不确定是否还有其他事情，或者是对还是错。 如果需要任何技术来解决，请基于Java进行思考。 谢谢。

15 java  serialization 

我们通过各种服务处理消息（一条消息在完成之前可能会涉及9个服务，每个服务都具有与IO相关的特定功能）。现在，我们结合了最坏情况（XML数据协定序列化）和最佳情况（内存中的MSMQ）的性能。 消息的性质意味着我们的序列化数据最终约为12-15 KB，并且我们每周处理约400万条消息。MSMQ中的持久消息对我们来说太慢了，随着数据的增长，我们感受到了MSMQ的内存映射文件带来的压力。 该服务器的内存使用量为16GB，并且正在增长，仅用于排队。 当内存使用率很高时，由于机器开始交换，因此性能也会受到影响。我们已经在执行MSMQ自清除行为。 我觉得这里有些地方我们做错了。我尝试使用RavenDB保留消息并仅对标识符进行排队，但性能却非常慢（每分钟最多1000条消息）。我不确定这是使用开发版本还是使用什么版本，但我们确实需要更高的吞吐量[1]。该概念在理论上非常有效，但性能不能满足要求。 使用模式具有一项充当路由器的服务，该服务会进行所有读取。其他服务将基于它们的第3方挂钩附加信息，然后转发回路由器。大多数物体被触摸9至12次，尽管大约10％的物体在该系统中被迫循环一会儿，直到第三方做出适当响应为止。现在，由于这一原因，我们利用消息的优先级字段来解决此问题并具有适当的休眠行为。 因此，我的问题是，在C＃/ Windows环境中用于在离散但LAN的计算机之间传递消息的理想堆栈是什么？ 我通常从BinaryFormatter而不是XML序列化开始，但是如果更好的方法是将序列化卸载到文档存储中，那就太麻烦了。因此，我的问题。 [1]：我们的业务性质意味着我们越早处理消息，我们就越赚钱。我们已经通过经验证明，在本周晚些时候处理一条消息意味着我们赚钱的可能性较小。虽然“每分钟1000个”的性能听起来非常快，但我们确实需要将该数字提高到1万个/分钟。仅仅因为我每周在消息中提供数字并不意味着我们有整整一周的时间来处理这些消息。 ===============编辑： 附加信息 根据评论，我将添加一些说明： 我不确定序列化是我们的瓶颈。我已经对应用程序进行了基准测试，虽然序列化确实显示在热图上，但它仅占服务CPU利用率的2.5-3％。 我最担心的是我们消息的持久性和对MSMQ的潜在滥用。我们使用的是非事务性，非持久性消息，因此我们可以保持排队性能，而且我真的很希望至少有持久性消息，以便它们在重新启动后仍能生存。 添加更多的RAM是权宜之计。机器的内存已经从4GB减少到了16GB，并且越来越难以取舍以继续增加容量。 由于应用程序的星形路由模式，对象弹出一半时间然后被推到队列中，它根本不会改变。这又使（IMO）能够将其存储在其他地方的某种键值存储中，并仅传递消息标识符。 星型路由模式是应用程序不可或缺的，并且不会更改。我们无法以应用程序为中心，因为此过程中的每一部分都异步运行（以轮询方式），并且我们希望将重试行为集中在一个地方。 应用程序逻辑是用C＃编写的，对象是不可变的POCO，目标部署环境是Windows Server 2012，如果仅在Linux中支持特定软件，则允许我们站立其他计算机。 我的目标是保持当前吞吐量，同时以最小的资本支出减少内存占用并提高容错能力。

13 serialization  queueing 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 6年前关闭。 我对开发使用Java编写的面向用户的大型网站感兴趣。 至于设计，我正在考虑开发独立的模块化服务，这些服务可以作为我的主要Web应用程序的数据提供者。 至于编写这些模块化服务（数据提供程序），我可以利用现有的框架（如Spring）并按照RESTful设计模式开发这些服务，并通过HTTP和消息格式（如JSON）公开资源...或者我可以利用现有的网络像Netty这样的框架（http://netty.io/）和像Protobufs这样的序列化格式（https://developers.google.com/protocol-buffers/docs/overview），并开发一个TCP服务器来来回发送序列化的protobuf有效载荷。 您何时应选择一个？使用Protobufs之类的序列化格式并通过网络发送字节流会有任何好处吗？仅使用JSON会产生开销吗？使用TCP / IP和使用HTTP之间有多少开销？什么时候应该使用Spring over Netty来建立这样的服务，反之亦然？

13 java  rest  http  serialization  tcp 

一个简单的问题：我了解C＃中的序列化需要默认构造函数。这将消除使用构造函数注入的DI的可能性（在我的阅读中，通常是DI的首选样式[需要引用]）。那么，这真的是一种非此即彼的情况，还是我错过了一些东西？ （附带问题）：IoC容器是否以某种方式回避了这种折衷方案？

9 dependency-injection  serialization