-------------------对象序列化----20110629--------------------
对于一个存在于Java虚拟机中的对象来说，其内部的状态只保持在内存中。JVM停止之后，这些状态就丢失了。在很多情况下，对象的内部状态是需要被持久化下来的。提到持久化，最直接的做法是保存到文件系统或是数据库之中。这种做法一般涉及到自定义存储格式以及繁琐的数据转换。对象关系映射（Object-relational mapping）是一种典型的用关系数据库来持久化对象的方式，也存在很多直接存储对象的对象数据库。对象序列化机制（object serialization）是Java语言内建的一种对象持久化方式，可以很容易的在JVM中的活动对象和字节数组（流）之间进行转换。除了可以很简单的实现持久化之外，序列化机制的另外一个重要用途是在远程方法调用中，用来对开发人员屏蔽底层实现细节。
由于Java提供了良好的默认支持，实现基本的对象序列化是件比较简单的事。待序列化的Java类只需要实现Serializable接口即可。Serializable仅是一个标记接口，并不包含任何需要实现的具体方法。实现该接口只是为了声明该Java类的对象是可以被序列化的。实际的序列化和反序列化工作是通过ObjectOuputStream和ObjectInputStream来完成的。ObjectOutputStream的writeObject方法可以把一个Java对象写入到流中，ObjectInputStream的readObject方法可以从流中读取一个Java对象。在写入和读取的时候，虽然用的参数或返回值是单个对象，但实际上操纵的是一个对象图，包括该对象所引用的其它对象，以及这些对象所引用的另外的对象。Java会自动帮你遍历对象图并逐个序列化。除了对象之外，Java中的基本类型和数组也是可以通过 ObjectOutputStream和ObjectInputStream来序列化的。
http://www.infoq.com/cn/articles/cf-java-object-serialization-rmi
-----------------------------20110629--------------------
--------------------------- DTO与领域对象--20110630-----------------
问题的关键在于“在边界处，应用并不是面向对象的”。如你所见，大多数序列化技术都要求public、默认的构造方法以及可写的属性。本质上，在设计DTO时，这些要求会迫使你打破封装和数据隐藏的原则。甚至连基本的不变性，如要求字段不为null/不为空都不可能实现，因为DTO会忽略掉一切。Mark Seemann继续证明自己的论断：
.服务共享模式与契约，而非类。
.DTO并不会破坏封装，以为他们根本就不是对象。
根据这种情况，Mark提出了3种观点：
第1种观点是坚持已有的观念。为了消除隔阂，我们必须得开发一个转换层，用于将DTO转换为封装良好的领域对象。这正是书中的示例所采取的方式。然而，我越发觉得这种解决方案并不是最佳的。这会导致可维护性的问题（这也是我写书时所遇到的问题：当你写完后，你所知道的要比刚开始动笔时多不少，我并不是说书不好，只是想说它并不完美而已）。
第2种观点是不再将数据当作对象，将其看作是它自身所表示的结构化数据。如果我们所用的编程语言有单独的结构化数据概念就太好了。有趣的是，虽然C#并没有这个概念，但F#却有多种方式来建模数据结构而不涉及行为。或许这是更好的数据处理方式，我还要多尝试几次才行。
第3种观点是使用动态类型。在文章Cutting Edge: Expando Objects in C# 4.0中，Dino Esposito介绍了通过动态方法来使用结构化数据，这可以更快速地自动生成代码并向结构化数据提供轻量级的API。这种方法更有前途，它并没有提供编译期的反馈，但这只不过是一种安全上的错觉而已。我们需要通过单元测试来快速获取反馈，但我们一直都在使用TDD，不是么？
http://www.infoq.com/cn/news/2011/06/DTOs-vs-Objects
--------------------------- --20110630--------------------
对于一个存在于Java虚拟机中的对象来说，其内部的状态只保持在内存中。JVM停止之后，这些状态就丢失了。在很多情况下，对象的内部状态是需要被持久化下来的。提到持久化，最直接的做法是保存到文件系统或是数据库之中。这种做法一般涉及到自定义存储格式以及繁琐的数据转换。对象关系映射（Object-relational mapping）是一种典型的用关系数据库来持久化对象的方式，也存在很多直接存储对象的对象数据库。对象序列化机制（object serialization）是Java语言内建的一种对象持久化方式，可以很容易的在JVM中的活动对象和字节数组（流）之间进行转换。除了可以很简单的实现持久化之外，序列化机制的另外一个重要用途是在远程方法调用中，用来对开发人员屏蔽底层实现细节。
由于Java提供了良好的默认支持，实现基本的对象序列化是件比较简单的事。待序列化的Java类只需要实现Serializable接口即可。Serializable仅是一个标记接口，并不包含任何需要实现的具体方法。实现该接口只是为了声明该Java类的对象是可以被序列化的。实际的序列化和反序列化工作是通过ObjectOuputStream和ObjectInputStream来完成的。ObjectOutputStream的writeObject方法可以把一个Java对象写入到流中，ObjectInputStream的readObject方法可以从流中读取一个Java对象。在写入和读取的时候，虽然用的参数或返回值是单个对象，但实际上操纵的是一个对象图，包括该对象所引用的其它对象，以及这些对象所引用的另外的对象。Java会自动帮你遍历对象图并逐个序列化。除了对象之外，Java中的基本类型和数组也是可以通过 ObjectOutputStream和ObjectInputStream来序列化的。
http://www.infoq.com/cn/articles/cf-java-object-serialization-rmi
-----------------------------20110629--------------------
--------------------------- DTO与领域对象--20110630-----------------
问题的关键在于“在边界处，应用并不是面向对象的”。如你所见，大多数序列化技术都要求public、默认的构造方法以及可写的属性。本质上，在设计DTO时，这些要求会迫使你打破封装和数据隐藏的原则。甚至连基本的不变性，如要求字段不为null/不为空都不可能实现，因为DTO会忽略掉一切。Mark Seemann继续证明自己的论断：
.服务共享模式与契约，而非类。
.DTO并不会破坏封装，以为他们根本就不是对象。
根据这种情况，Mark提出了3种观点：
第1种观点是坚持已有的观念。为了消除隔阂，我们必须得开发一个转换层，用于将DTO转换为封装良好的领域对象。这正是书中的示例所采取的方式。然而，我越发觉得这种解决方案并不是最佳的。这会导致可维护性的问题（这也是我写书时所遇到的问题：当你写完后，你所知道的要比刚开始动笔时多不少，我并不是说书不好，只是想说它并不完美而已）。
第2种观点是不再将数据当作对象，将其看作是它自身所表示的结构化数据。如果我们所用的编程语言有单独的结构化数据概念就太好了。有趣的是，虽然C#并没有这个概念，但F#却有多种方式来建模数据结构而不涉及行为。或许这是更好的数据处理方式，我还要多尝试几次才行。
第3种观点是使用动态类型。在文章Cutting Edge: Expando Objects in C# 4.0中，Dino Esposito介绍了通过动态方法来使用结构化数据，这可以更快速地自动生成代码并向结构化数据提供轻量级的API。这种方法更有前途，它并没有提供编译期的反馈，但这只不过是一种安全上的错觉而已。我们需要通过单元测试来快速获取反馈，但我们一直都在使用TDD，不是么？
http://www.infoq.com/cn/news/2011/06/DTOs-vs-Objects
--------------------------- --20110630--------------------
扫一扫
5239
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
