最近正在研究Caché数据库，因为我是用.net开发，所以注意到有两种可用的开发模式：

1、通过InterSystems.Data.CacheClient，使用ADO.net读写数据库，这与使用sql sever或oracel是一样的，虽然方便但不能发挥Cache多维数据库的优势。
2、使用Caché代理对象。代理对象是通过工具从Caché中以定义对象导出的.net受控类，可以在.net 项目中直接使用。这样，在.net中就可以享受到对象直接保存到数据库的好处了，但这样必须在Caché中先定义类。这样的话，是否意味着很多的业务逻辑都要放到数据库中去定义呢？这是我们设计人员最不愿的事情啊！
哪种方式更好呢？想听听大家的想法或在以后的使用中摸索．

楼上说的没错，这正是我一直对Cache不感冒的原因

问这个问题是因为你还是把Cache'当数据库看，其实，Cache'是一个带数据存储引擎的面向对象开发工具啊。如果你不喜欢在Cache'里实现，那在别的开发环境里实现，用Cache'调用好了，也很方便啊

你开发系统的要求是什么？如果是比别人性能好，功能多的系统，那么Cache'非常值得考虑。如果是“我就想写一套代码，在任何数据库上都能跑。本身系统不会有性能瓶颈（小系统？）或者我不考虑性能问题，就考虑通用”，那么，Cache'只是你系统需要兼容的数据库之一，你实际上不能用任何数据库提供的特性（因为每个数据库的高级特性都可能和别的数据库不兼容），所以你的系统一定不是最好的，但的确可以尽可能做到在“特定操作系统平台”下的数据库兼容性。但想想现在你要面对的不仅仅是数据库，还有操作系统-我要系统可以跑在Windows、Linux、Solaris上，怎么办？按照这个思路，应该将所有的逻辑、数据都封装在一个能跑在所有主流操作系统平台上的开发环境里（逻辑+数据），而这就是Cache'。所以，要真的兼容，Cache'仍是你应该好好考虑的。

ctiger说的没错，我就是要将它作为数据。因为用Cache'的原因主要是它的多维数据库所提供的高性能及面向对象特性，但我不想要的是Cache'的开发环境与COS。这是因为：

1、COS是专属语言，开发人员有一个学习的过程

2、COS的语法机制与JAVA、C＃比起来是有差距的，而且COS与上述语言一样都是基于虚拟机机制，相信它基于托管封装的标准类库不如前者丰富（猜测）。但一个实用的HIS系统肯定有很多的复杂业务逻辑及对操作系统功能的调用。这些我想COS都有差距。

3、Cache'的开发环境与VS2005等的差距。

所以我现在的想法是只在Cache'中定义简单类，这个类只包含基本的字段。然后使用代理对象的方式生成C＃类，再将此C＃类进行一次或多次继承、加入业务逻辑方法。这样也定义好了数据结构。当然，对于对数据库操作多、性能要求高的一些操作，也可以在Cache'类中写一些方法（就相当于关系数据库中的存储过程）。

1、COS的语法并不是很复杂和奇怪，和其他的开发语言类似。一般的开发者在接受一周的培训之后就可以上手了。

2、COS是在cache数据库的基础上，在编译以后是在数据库中的二进制代码，这个和JAVA等在本质上还是有很大的区别。毕竟这些语言是应用层的，而COS是数据库层（CSP虽然可以开发应用，但是编译以后也是类，存在数据库里）的。如果，开发HIS，在cache的成功案例已经举不胜举了。我认为你说的“开发HIS”的差距，应该是在应用架构时的一些手法的差距，而不是工具的差距。国际上采用cache开发HIS的厂商不少，他们并不认为面向对象的设计会有什么复杂的业务逻辑难以实现。至少，远比二维的关系数据库实现起来方便。

3、在用户友好度上，cache的studio是比不上VS2005。毕竟后一个开发环境，其发展的历史之长，微软帝国在它上面花费的人力和物力之大，是大家都知道的。cache的studio比起以前已经在长足的发展了，那么，发展是个过程。

想听听有实际应用经验的大虾说说！

新手，关注ing

补充几点：

1。COS是可以“摸到“系统底层的：可以用COS命令操作磁盘文件、串口、进程、TCP、电邮等等“对操作系统功能的调用”，而且可以作为COM客户端重用COM组件（将类型库导出为Cache'的包装类），以及一定格式的dll

这些命令（除了win特定的）在各种操作系统下的调用形式是一样的，它们在不同OS下的具体实现操作已经被封装成为了统一形式。

2。Cache'提供了Cache' Basic语言，更容易学习。

3。Cache'中的逻辑代码是距离数据最近的，而对于事务、分布式、伸缩性和快速部署等需求Cache'也已经很好地解决了。

4。如果在与Cache'异构的系统中来实现关键业务逻辑，整体性能会有很大影响。

强调一点，把Cache'当作纯数据库来用将很难体现出它的特点。

如题，谢谢。