或许你已经从种种渠道得知10gen JVM小组正在致力于3.0版本的Java驱动开发，然而如果你了解这项起于2012年底的项目至今却尚未完成，肯定会感叹一句“10gen的哥们，又打酱油了吧”。近日MongoDB Java工程师及布道者Trisha Gee在公司博客中撰文解释了这个原因，并为我们揭开了新版本驱动的面纱，以下为译文：
那么为什么要废如此功夫去更新驱动，我们又想达到什么目的？OK，下面看一下需求：
更容易维护 更容易扩展 更好的支持ODM、第三方库以及其它的JVM语言 给Java开发者更好的体验
不错，非常概括，基本上可以理解为驱动的全面提升，所以我们需要更切实的目标：
一致性 更清晰的设计 直观的API 容易理解的异常 友好的测试 向后兼容 一致性
Java开发者在使用驱动时发现了许多不一致的地方：Java驱动中的用法会不同于shell或者是其它驱动；甚至使用Java驱动时，方法命名的方式同样让人困惑（CreateIndex与ensureIndex）；参数的顺序也经常不同；有时候方法被重载多次，你还是会使用method chain。虽然存在QueryBuilder，但是有许多场景下你还是需要手动的构造一个DBObject，等等。
如果你在使用这个驱动，即使你有轻微的强迫症，代码的一致性也可能让你发疯：空格的用法、花括号的位置、字段的位置、混淆的字段名称等等。有些人可能会对此不屑一顾，但是对于驱动初学者来说确实造成了不必要的困扰，同样这也意味着增加特性或者是修复bug将花费更长的时间。
更清晰的设计
其实驱动的义务非常的简单及单一，即负责Java和BSON的转换。毕竟，其根本责任就是扮演应用程序和MongoDB之间的桥梁，而做的也是将方法调用和Java对象转换成wire-protocol消息，反之亦然。不错，这是驱动本分，但绝对不是唯一。MongoDB支持横向扩展，这就意味着应用程序可能会运行在多台主机之上——可能在从节点中的一个读取数据，也可能在分片的环境中进行读取，当然也可以只有一台服务器。而驱动的目的就是让这一切对应用透明，所以它就像是在做server discovery，选择合适的服务器，并在适当的地方尝试重用连接。连接池的管理同样由其完成，还有序列化和反序列化，这里存在一个完整的连接管理模块。
驱动的作用还包括在协议和应用之间提供一个恰当的抽象级：驱动有着自己的域，而这个域需要以相同的表现形式设计——与Document、Collection、Database相同，让用户可以更加直观的使用。
显然驱动的设计目标不仅仅是为应用开发者使用。通过合适的设计，我们可以让其它的库及驱动更容易重用一些low-level代码（比如BSON协议、连接管理等），而上方使用的是自己的API——比如Spring Data、Morphia以及其它JVM语言（比如Scala）。取代将驱动作为Java开发者连接MongoDB的默认方式，我们更愿意将它设计成JVM驱动，让你可以在上面建立正确的抽象等级，因此内部构件可以更容易的为其它库重用。
为了实现这些，我们必须重新设计驱动，而核心就是围绕用户API的封装——就我们而言，我们需要提供一个非常类似旧版本的逆向兼容API。核心就是ODM和其它驱动在提供自己API的同时可以重用一些通用功能。这样就保证了横跨多个JVM驱动与库在和数据库通信时的一致性，同样允许应用开发者通过最直观的API去使用这个库来满足需求。
直观的API
我们想建立一个这样的API：
让Java开发者感觉非常熟悉 通过shell与MongoDB通信的逻辑是否符合你知道的（鉴于大多数我们的帮助文档都引用了shell） 是否与其它语言驱动一致
基于这些需求，新版驱动的耗时就完全符合逻辑了。至今这些需求仍然在努力当中，从Java的角度上讲，我们需要完成以下几个点：
- 静态类型是Java的一个优势，所以我们也不能失去它。我们渴望IDE来帮助你，当你在尝试决定使用哪个方法及他们的参数时，我们期望Cmd+space就可以给出正确答案。 泛型。已经被使用近10年，我们希望在驱动中也可以存在。 我们期望MongoDB中名称和协议的使用会有一个非常好的体验，所以不会再有DBObject，请期待Document吧。 在建立查询和对象时有更多的帮助，更加容易理解并且拥有自描述。
可以理解的异常
当你为别人排错时，许多驱动抛出的异常显得毫无用处。甚至用户都无法确定这个异常的抛出者（服务器还是驱动），所以我们引入了客户端和服务器的异常概念。我们还引入了一些其它异常，所以取代得到一个MongoException和一些需要许多工作才可以理解的异常，我们为各种不同场景设计指定的异常（比如，MongoInvalidDocumentException）。
友好的测试
我在写第一个MongoDB与Java应用程序时做的第一件事就是mock驱动——如果你想做一些综合测试，你可能同样会mock或者stub驱动，这样你就可以分离MongoDB对程序进行测试。但是这里完全不行，所有类都被定义为final，并且这里不存在任何接口。即使在数据库上可以执行系统、整合、功能测试，同样存在区域隔离测试的需求，我们需要一种简单、快速的测试，可以检查工作是否如预期的执行。
新的驱动使用了API级别接口，这样就可以mock驱动来测试应用程序，清晰和解耦的设计让其可以更容易的进行驱动内部构件测试。当下我们已经在功能和单元上同时实施Spock测试，用以提升内部驱动测试的范围和可读性。
此外，我们还在acceptance测试（Java中，而不是Groovy或Spock）上做了努力。这里的目标就是为驱动建立一个动态的文档——不仅是如何去操作，同样包括了很多计划外发生事情的记录。同样许多工作尚未完成，我们期望随着时间的增长，这些问题都会被改善及解决。
向后兼容
同样重要的是，所有这些大型重设计、架构以及API都必须是向后兼容的。我们致力于现有客户，当然不希望他们在接受新驱动时要做太多操作上的改变。我们期望升级可以温和的进行，即使这样会给驱动的开发带来很多困难，但是我们认为可以更好的对新驱动进行验证——取代摒弃现有功能，我们可以在新驱动下兼容的运行当下测试套件，从而来验证结果是否相同。
总结
从MongoDB的官方博客中，我们不难发现新的驱动对Java开发者更加友好，然而用户最关心的异步支持并未出现在任务列表中。但值得庆幸的是，而文章后的用户提问中，Trisha Gee指出新驱动的设计已经考虑异步支持。虽然不能保证在3.0版本中得以释放，但是在下一个版本肯定会得以实现。
The MongoDB Java Driver 3.0（编译/仲浩 审校/周小璐）
更多内容请关注CSDN云计算频道 及@CSDN云计算微博
自己选择的路，跪着也要把它走完。
