很多项目中都有消息分发或者事件通知机制,尤其是模块化程度高的项目。
比如:在你的系统中,很多模块都对 新建用户 感兴趣。权限模块希望给新用户设置默认权限,报表模块希望重新生成当月的报表,邮件系统希望给用户发送激活邮件...诸如此类的代码都写到新建用户的业务逻辑后面,会加大耦合度,降低可维护性,并且对于每个模块都是一个独立系统的情况,这种方式更是不可取。
对于简单的情形,观察者模式 The Observer Pattern
就足够了。如果系统中有很多地方都需要收发消息,那么它就不适用了。否则会造成类数量的膨胀,增加类的复杂性,这时候就需要一种更集中的机制来处理这些业务逻辑。
现实中,并不是所有请求都期待答复,而不期待答复,自然就没有了状态。广播听过吧?收音机用过吧?就这个意思。
发布/订阅模式定义了一种一对多的依赖关系,让多个订阅者对象同时监听某一个主题对象。这个主题对象在自身状态变化时,会通知所有订阅者对象,使它们能够自动更新自己的状态。
filter
丢掉自己不需要的消息 (filter
是在订阅端起作用的)push
,其中消息自动地向订阅者广播,它们无须请求或轮询主题来获得新消息发布/订阅模式内部,有多种不同类型的订阅者。
Publisher
中。与其说缺陷,不如说它设计本身就有如下特点。但不管怎么说,这种模式在逻辑上不可靠的。主要体现在:
你可能早就看过 RailsCasts 上的 #260 Messaging with Faye 和 #316 Private Pub。但今天要来介绍的是另外一个 gem。
callback
的实现Post
模型通过回调,与 Feed
模型和 User::NotifyFollowers
服务紧密的耦合在一起。
# app/models/post.rb
class Post
after_create :create_feed, :notify_followers
def create_feed
Feed.create!(self)
end
def notify_followers
User::NotifyFollowers.call(self)
end
end
# app/controllers/api/v1/posts_controller.rb
class Api::V1::PostsController < Api::V1::ApiController
def create
@post = current_user.posts.build(post_params)
if @post.save
render_created(@post)
else
render_unprocessable_entity(@post.errors)
end
end
end
Wisper
的 PUB-SUB 模式# app/models/post.rb
class Post
# no callbacks in the models!
end
Publishers 在对象状态改变且需要触发事件的时候发布事件。
# app/controllers/api/v1/posts_controller.rb
# corresponds to the publisher in the previous figure
class Api::V1::PostsController < Api::V1::ApiController
include Wisper::Publisher
def create
@post = current_user.posts.build(post_params)
if @post.save
# Publish event about post creation for any interested listeners
publish(:post_create, @post)
render_created(@post)
else
# Publish event about post error for any interested listeners
publish(:post_errors, @post)
render_unprocessable_entity(@post.errors)
end
end
end
Subscribers 仅接收它们能响应的事件。
# app/listener/feed_listener.rb
class FeedListener
def post_create(post)
Feed.create!(post)
end
end
# app/listener/user_listener.rb
class UserListener
def post_create(post)
User::NotifyFollowers.call(self)
end
end
Event Bus 用来管理系统中订阅者都订阅哪些频道。
# config/initializers/wisper.rb
Wisper.subscribe(FeedListener.new)
Wisper.subscribe(UserListener.new)
Publisher
# app/service/financial/order_review.rb
class Financial::OrderReview
include Wisper::Publisher
def self.call(order)
if order.approved?
publish(:order_create, order)
else
publish(:order_decline, order)
end
end
end
Subscribers
# app/listener/client_listener.rb
class ClientListener
def order_create(order)
# can implement transaction using different service objects
Client::Charge.call(order)
Inventory::UpdateStock.call(order)
end
def order_decline(order)
Client::NotifyDeclinedOrder(order)
end
end
更多用法,请参考 Wisper wiki。
本文的唯一作用可能就是,能让大家在设计 Service Objects
时候再多思考一点。虽然到底要不要抽出 Service Objects
也是一个见仁见智的问题。在相关连接中我有贴出 Gourmet Service Objects 一文,另外本站的 Service Object: What? Why? and How? 也请抽空读一下。
这里没有交代如何在发布/订阅模式中引入队列系统的方法,所以上面的代码你是绝对没办法直接拿去用的。