我和Gary打算开发一款适合小应用的，快速存储解决方案 -- Small App Storage。所有的数据存取都在C#对象的存储和访问间完成。于是今天和Gary讨论了一些sas的具体需求以及存储接口的问题，产生了几个主要意见分歧：

1. 何种类型可以被存储：

我的意见是，在C#中模拟JS中的几个基本类型，限制只能存储这几种基本类型。基本类型有 String, Number, Boolean, Array, Object。并在C#中模拟这些JS基本类型的特性。

理由是这些基本类型基本上可以满足所有小应用开发的需要。而且纵观现在的数据库，也基本提供了类似的类型，如char, text, bool, int等，而二维表与表间的关系可以由Object对象间的引用来表达。

Gary的意见是不要和类型绑定的太死，他希望所有的C#类型都可以被存储。而这样就会产生几个问题：

1）C#中的类型众多，如何存储？考虑到enum,struct,还有各种类，还有对象的引用关系，存储文件的结构上也会变的很复杂，

2) 如果数据在存储时存储的类是ClassOld，在之后应用进行了refactor，ClassOld的类名变成了ClassNew，数据如何还原？

2 第二个分歧也是由第一个分歧产生的。我希望每当同一个c#对象付给存储对象时，不会新生成一个数据记录。伪代码如下：

Storage s = new Storage(AppId);

Number n = new Number(234);

s.Root["A"] = n;

n.Value = 567;

s.Root["B"] = n;

我的想法是s.Root["B"]和s.Root["A"]能取到同一个对象，既s.Root["A"].Value最后的指为567。

这样的好处是和C#中的操作类似，因为Number为引用类型，应该指向同一个对象。而且本来应用的目的就是模拟C#对象操作，在对象操作的瞬间就存储数据。

但Gary认为Storage为存储对象，以一般存储数据库的行为思考，他应该是建立了一个新数据。而且如果分歧1中他的意见成立，那么就可以直接付值值类型。

s.Root["A"] =234；

另外，如果每次新生成一个数据，那么就可以用Xml很容易的表示对象的层次结构。

而我觉得，即使直接付值类型，他也会被boxing，变成reference type。而且，如果既要存储对象层次关系，又要复制值。那么当我存储一个环状链表时，程序就会进入死循环，不停的将引用当成新数据写入。而且如果我们在1.0版中不对引用进行支持，那么就同AppSettings没有区别了，也只能存储值类型数据。

3. 关于数据存储的接口，我认为它不用管C#对象的层次关系，所有的存储和读取都以对象ID号进行。在new Storage时，得到一个Root对象，根据Root对象的Children Information可以得到Children Reference ID和Children Keys。根据Children ID又可以得到下一级的Children ID。从而实现完全对对象引用的模拟，从而解决分歧2中引用到同一个数据难的问题。

Gary的观点认为，数据存储时应该提供对象层次的关系，从而在XML中做对应的层次映射。

从根本上说，Gary倾向与用Xml原由的层次关系来描述对象。而我倾向与用一个线行的表结构来描述所有对象，就有点像Heap一样，Object的实际内容都存放在Heap里，而用一个Reference来表明他们之间的关系。