可以使用视图和更新处理程序导致Couch对文档结构了解太多吗？

Question

我最近向我的团队提出了一些想法：

“嘿伙计们我们在.NET层中做的很多事情Couch已经通过视图和更新处理程序支持了。”

e.g：

返回文档时：我们希望返回没有_rev字段的文档和“REST” - 对其他文档的引用或者也包含该文档。

插入文档时：我们希望能够提供一个看起来很像执行get时返回给用户的对象。

更新时：我们希望允许就地更新（或至少是幻觉）。

所有这些对于Couch视图和更新处理程序来说似乎都是微不足道的;但我反对的最大争议是Couch会对文档结构有太多的了解，这显然会导致维护问题并使得更换我们的数据访问层变得更加困难。

是否有任何最佳实践指南说“是的，这个东西很酷”或“不，你从来不想这样做”？

Answer 1

确实如此，_show，_update和_list函数对非人类的东西不是很有用。基本上你把一半的逻辑放在CouchDB Javascript中，一半放在客户端。您必须始终使服务器端Javascript与客户端保持同步。您可能无法使用相同的服务器端代码运行不同版本的客户端软件。

当_show，_update和_list有用时，有三种例外情况。

1. 如果远程客户端需要某个数据（XML，HTML等），_show和_list就不错了。
2. 如果真的需要使用更少的带宽，这些功能可以制作特定于应用程序的压缩协议。也就是说，就地更新的_update函数只是一种压缩方式，可以说“获取此文档，更新一个项目，然后存储新文档。”
3. 如果您有许多不同的客户类型，不同的语言，不同的版本，不同的错误等，那么您可以使客户尽可能简单并使Couch尽可能智能化。