rails mysql adapter_解读Rails - 适配器模式

电玩女神 2022-11-05 15:55 152阅读 0赞

今天我们暂时先放下具体的代码片段，我们将要对Rails中所实现的一个比较常见的设计模式进行一番探索，这个模式就是适配器模式(Adapter Pattern)。从一定的意义上来说，这次的探索并不全面，但是我希望能够突出一些实际的例子。

为了跟随本文的步骤，请使用qwandry打开相关的代码库，或者直接在Github上查看这些代码。

适配器模式

适配器模式可以用于对不同的接口进行包装以及提供统一的接口，或者是让某一个对象看起来像是另一个类型的对象。在静态类型的编程语言里，我们经常使用它去满足类型系统的特点，但是在类似Ruby这样的弱类型编程语言里，我们并不需要这么做。尽管如此，它对于我们来说还是有很多意义的。

当使用第三方类或者库的时候，我们经常从这个例子开始(start out fine)：

def find\_nearest\_restaurant(locator)

locator.nearest(:restaurant, self.lat, self.lon)

end

我们假设有一个针对locator的接口，但是如果我们想要find\_nearest\_restaurant能够支持另一个库呢？这个时候我们可能就会去尝试添加新的特殊的场景的处理：

def find\_nearest\_restaurant(locator)

if locator.is\_a? GeoFish

locator.nearest(:restaurant, self.lat, self.lon)

elsif locator.is\_a? ActsAsFound

locator.find\_food(:lat => self.lat, :lon => self.lon)

else

raise NotImplementedError, "\#\{locator.class.name\} is not supported."

end

这是一个比较务实的解决方案。或许我们也不再需要考虑去支持另一个库了。也或许find\_nearest\_restaurant就是我们使用locator的唯一场景。

那假如你真的需要去支持一个新的locator，那又会是怎么样的呢？那就是你有三个特定的场景。再假如你需要实现find\_nearest\_hospital方法呢？这样你就需要在维护这三种特定的场景时去兼顾两个不同的地方。当你觉得这种解决方案不再可行的时候，你就需要考虑适配器模式了。

在这个例子中，我们可以为GeoFish以及ActsAsFound编写适配器，这样的话，在我们的其他代码中，我们就不需要了解我们当前正在使用的是哪个库了：

def find\_nearest\_hospital(locator)

locator.find :type => :hospital,

:lat => self.lat,

:lon => self.lon

end

locator = GeoFishAdapter.new(geo\_fish\_locator)

find\_nearest\_hospital(locator)

特意假设的例子就到此为止，接下来让我们看看真实的代码。

MultiJSON

ActiveSupport在做JSON格式的解码时，用到的是MultiJSON，这是一个针对JSON库的适配器。每一个库都能够解析JSON，但是做法却不尽相同。让我们分别看看针对oj和yajl的适配器。

(提示: 可在命令行中输入qw multi\_json查看源码。)

module MultiJson

module Adapters

class Oj < Adapter

\#...

def load(string, options=\{\})

options\[:symbol\_keys\] = options.delete(:symbolize\_keys)

::Oj.load(string, options)

end

\#...

Oj的适配器修改了options哈希表，使用Hash\#delete将:symbolize\_keys项转换为Oj的:symbol\_keys项：

options = \{:symbolize\_keys => true\}

options\[:symbol\_keys\] = options.delete(:symbolize\_keys) \# => true

options \# => \{:symbol\_keys=>true\}

接下来MultiJSON调用了::Oj.load(string, options)。MultiJSON适配后的API跟Oj原有的API非常相似，在此不必赘述。不过你是否注意到，Oj是如何引用的呢？::Oj引用了顶层的Oj类，而不是MultiJson::Adapters::Oj。

现在让我们看看MultiJSON又是如何适配Yajl库的：

module MultiJson

module Adapters

class Yajl < Adapter

\#...

def load(string, options=\{\})

::Yajl::Parser.new(:symbolize\_keys => options\[:symbolize\_keys\]).parse(string)

end

\#...

这个适配器从不同的方式实现了load方法。Yajl的方式是先创建一个解析器的实力，然后将传入的字符串string作为参数调用Yajl::Parser\#parse方法。在options哈希表上的处理也略有不同。只有:symbolize\_keys项被传递给了Yajl。

这些JSON的适配器看似微不足道，但是他们却可以让你随心所欲地在不同的库之间进行切换，而不需要在每一个解析JSON的地方更新代码。

ActiveRecord

很多JSON库往往都遵从相似的模式，这让适配工作变得相当轻松。但是如果你是在处理一些更加复杂的情况时，结果会是怎样？ActiveRecord包含了针对不同数据库的适配器。尽管PostgreSQL和MySQL都是SQL数据库，但是他们之间还是有很多不同之处，而ActiveRecord通过使用适配器模式屏蔽了这些不同。(提示: 命令行中输入qw activerecord查看ActiveRecord的代码)

打开ActiveRecord代码库中的lib/connection\_adapters目录，里边会有针对PostgreSQL,MySQL以及SQLite的适配器。除此之外，还有一个名为AbstractAdapter的适配器，它作为每一个具体的适配器的基类。AbstractAdapter实现了在大部分数据库中常见的功能，这些功能在其子类比如PostgreSQLAdapter以及AbstractMysqlAdapter中被重新定制，而其中AbstractMysqlAdapter则是另外两个不同的MySQL适配器——MysqlAdapter以及Mysql2Adapter——的父类。让我们通过一些真实世界中的例子来看看他们是如何一起工作的。

PostgreSQL和MySQL在SQL方言的实现稍有不同。查询语句SELECT \* FROM users在这两个数据库都可以正常执行，但是它们在一些类型的处理上会稍显不同。在MySQL和PostgreSQL中，时间格式就不尽相同。其中，PostgreSQL支持微秒级别的时间，而MySQL只是到了最近的一个稳定发布的版本中才支持。那这两个适配器又是如何处理这种差异的呢？

ActiveRecord通过被混入到AbstractAdapter的ActiveRecord::ConnectionAdapters::Quoting中的quoted\_date引用日期。而AbstractAdapter中的实现仅仅只是格式化了日期：

def quoted\_date(value)

\#...

value.to\_s(:db)

end

Rails中的ActiveSupport扩展了Time\#to\_s，使其能够接收一个代表格式名的符号类型参数。:db所代表的格式就是%Y-%m-%d %H:%M:%S：

\# Examples of common formats:

Time.now.to\_s(:db) \#=> "2014-02-19 06:08:13"

Time.now.to\_s(:short) \#=> "19 Feb 06:08"

Time.now.to\_s(:rfc822) \#=> "Wed, 19 Feb 2014 06:08:13 +0000"

MySQL的适配器都没有重写quoted\_date方法，它们自然会继承这种行为。另一边，PostgreSQLAdapter则对日期的处理做了两个修改：

def quoted\_date(value)

result = super

if value.acts\_like?(:time) && value.respond\_to?(:usec)

result = "\#\{result\}.\#\{sprintf("%06d", value.usec)\}"

end

if value.year < 0

result = result.sub(/^-/, "") + " BC"

end

result

end

它在一开始便调用super方法，所以它也会得到一个类似MySQL中格式化后的日期。接下来，它检测value是否像是一个具体时间。这是一个ActiveSupport中扩展的方法，当一个对象类似Time类型的实例时，它会返回true。这让它更容易表明各种对象已被假设为类似Time的对象。(提示: 对acts\_like?方法感兴趣？请在命令行中执行qw activesupport，然后阅读core\_ext/object/acts\_like.rb)

第二部分的条件检查value是否有用于返回毫秒的usec方法。如果可以求得毫秒数，那么它将通过sprintf方法被追加到result字符串的末尾。跟很多时间格式一样，sprintf也有很多不同的方式用于格式化数字：

sprintf("%06d", 32) \#=> "000032"

sprintf("%6d", 32) \#=> " 32"

sprintf("%d", 32) \#=> "32"

sprintf("%.2f", 32) \#=> "32.00"

最后，假如日期是一个负数，PostgreSQLAdapter就会通过加上"BC"去重新格式化日期，这是PostgreSQL数据库的实际要求：

SELECT '2000-01-20'::timestamp;

\-- 2000-01-20 00:00:00

SELECT '2000-01-20 BC'::timestamp;

\-- 2000-01-20 00:00:00 BC

SELECT '-2000-01-20'::timestamp;

\-- ERROR: time zone displacement out of range: "-2000-01-20"

这只是ActiveRecord适配多个API时的一个极小的方式，但它却能帮助你免除由于不同数据库的细节所带来的差异和烦恼。

另一个体现SQL数据库的不同点是数据库表被创建的方式。MySQL以及PostgreSQL中对主键的处理各不相同：

\# AbstractMysqlAdapter

NATIVE\_DATABASE\_TYPES = \{

:primary\_key => "int(11) DEFAULT NULL auto\_increment PRIMARY KEY",

\#...

\# PostgreSQLAdapter

NATIVE\_DATABASE\_TYPES = \{

primary\_key: "serial primary key",

\#...

这两种适配器都能够明白ActiveRecord中的主键的表示方式，但是它们会在创建新表的时候将此翻译为不同的SQL语句。当你下次在编写一个migration或者执行一个查询的时候，思考一下ActiveRecord的适配器以及它们为你做的所有微小的事情。

DateTime和Time

当MultiJson以及ActiveRecord实现了传统的适配器的时候，Ruby的灵活性使得另一种解决方案成为可能。DateTime以及Time都用于表示时间，但是它们在内部的处理上是不同的。虽然有着这些细微的差异，但是它们所暴露出来的API却是极其类似的(提示：命令行中执行qw activesupport查看此处相关代码)：

t = Time.now

t.day \#=> 19 (Day of month)

t.wday \#=> 3 (Day of week)

t.usec \#=> 371552 (Microseconds)

t.to\_i \#=> 1392871392 (Epoch secconds)

d = DateTime.now

d.day \#=> 19 (Day of month)

d.wday \#=> 3 (Day of week)

d.usec \#=> NoMethodError: undefined method \`usec'

d.to\_i \#=> NoMethodError: undefined method \`to\_i'

ActiveSupport通过添加缺失的方法来直接修改DateTime和Time，进而抹平了两者之间的差异。从实例上看，这里就有一个例子演示了ActiveSupport如何定义DateTime\#to\_i：

class DateTime