天天好味道

# re: 刚开始学习Web 开发的MVC模式 - CakePHP

3.设计中，这个模式还强调了发布-订阅模式，就是说当M改变的时候，所有反映这个M的V都会更新.


这里我有个弱弱的问题：如果发布者在发布信息的时候，某个订阅者当时不在线（或者是当时网络不通），那么在以后，订阅者还有机会收到刚才的发布的那条信息不？

# to xiaohan:那要看怎么设计了

严格的讲，订阅者如果不存在了，他的订阅也会被取消，当然消息也不会给它了。
当然实际使用的时候，的确会有这种订阅者被销毁，而希望消息还能到达的情况，我的解决办法是要求订阅者死亡之前留下一架“骸骨”代替它来订阅，并且将数据暂存。这个“骸骨”其实就是所谓的Proxy模式。

你所得是涉及网络的情况，这条消息的重传应该是协议层的事情，跟发布-订阅模式无关。

# re: 刚开始学习Web 开发的MVC模式 - CakePHP

或许是我没有描述清楚，这样子：
发布者发布信息的时候，此时通往某个订阅者的路不通，那么发布者是等待通了以后发给此订阅者，还是直接抛弃。我的感觉好像是抛弃了。

我的感觉好像是发布者就广播了一下，然后至于订阅者是否收到，发布者就不关心了。是这样子吗？

# 是我没说清楚

发布-订阅模式 中有一个环节，就是如何发送数据变化或者数据本身。在网络应用中，这就会涉及到一个传输层，我会在这一层实现缓冲，重传等机制，因为只有它知道订阅者不通，发布者只管把消息送出去就好了。当然，如果你愿意，也可以在发布者这个层次实现这个逻辑。
设计模式不是不能改变的，那本书上写的是最经典的经验总结，实际使用的时候一般都要作变化的。

# re: 刚开始学习Web 开发的MVC模式 - CakePHP

呵呵，咱俩说的还是不一会事。我知道可以使用缓冲来延迟发送。但是由于我没有看过这个模式，所以我说的是我的直观感受：这种模式想udp--发送完就不管了。 如果说是这样子，我觉得也很对，这种模式就是和于那种只在乎当时能够连通的订阅者，因为事后订阅者再收到信息，也是垃圾信息了。例如：订阅电视报、订阅天气预报等。在第二天收到昨天的天气预报和昨天的电视节目，也许就没有意义了。

如果你使用订阅者模式，而自己又采用缓冲延迟发送的话，我觉得就不是和订阅者和发布者模式，我倒觉得自己应该搞另外的形式，自己轮询的去取，这样服务器也可以减少负担（主要是逻辑负担：不用挨个去查看那个订阅者当时没有收到信息），如果修改为订阅者（现在这么称呼已经不合适）来轮询查看是否有信息的消息，如果有，就把信息取过来，这样更合适。

一己之谈，不合适的思路或者是言语，请老兄谅解。 ：P

# to 晓寒

这个模式并没有规定一定要发送完就不管了，他也没有规定使用“拉”还是“推”来送达数据。 这个模式描述了这样一个重要的观点：数据的持有者不需要知道数据使用者的存在，也不用关心他们将如何使用。
他的工作是把数据送给想要的对象。注意这句话，他并没有规定这个数据是否应该准确送达。这个问题已经不是这个模式的一部分。

至于轮询，当然也是一种模式，他的优点和缺点都是非常突出的，在数据变化缓慢的情况下，轮询是非常浪费的，在数据疯狂变化的情况下，轮询则会丢失掉重要的消息，或者导致界面上的更新不连贯。 相反，在数据变化快的情况下，发布-订阅模式可能会严重的冲击系统，导致资源耗尽。

这些问题都应该具体分析。

给你举个例子，发布-订阅模式好比你跟邮局订报纸。只要报纸来了，他肯定给你送到信箱里。如果你肯多付钱的话，他也许可以保证亲自送到你手里，以免送信箱里的报纸因为某种原因你没收到。两种不同的方式，都是同一个模式，区别不在邮局，而在邮递员的工作方式（传输层）。

# re: 刚开始学习Web 开发的MVC模式 - CakePHP

呵呵，非常感谢你的详尽解释。

看来我对模式的理解不足。
：）

# 我应该谢谢你

最近正在构思一篇关于设计模式的帖子，跟你讨论让我思路又清晰了不少。:)

# re: 刚开始学习Web 开发的MVC模式 - CakePHP

期待你的设计模式帖子. 我很少看设计模式,都是道听途说的.

我刚才想了想,其实我说的延迟发送,的确不是模式的,是模式之后的东西,模式只是一个方式.其实我自己在我现在的工程中就用到的就有订阅者模式(只是我不知道,我认为是改进了的订阅者)，而我还用了两个地方，一个是可以延迟发送，一个是非延迟（当时不论是什么原因没有送达，都立即抛弃）。

# 那我推荐你有空看看

像你这样已经有丰富设计经验了，看设计模式收获最大了。
他可以把你一些存在但是不清晰的东西准确的描述出来，
让你一边读一遍发出“噢！原来如此”的感叹，这是最快乐的事情:)

# re: 刚开始学习Web 开发的MVC模式 - CakePHP

过奖过奖。

# re: jzhang

请问一下，你觉得数据变化快速的情况下，用哪种模式会比较适合呢？

另，发布订阅模式，也就是java离地事件机制所用的。在java里是耦合度很高的一种模式（当然这个也要看具体情况），有时，还会用一层中间代理，以便发布者和订阅者并不直接交互（当然，这个中间层也可以是订阅者兼发布者）。也就是说，大量的发布订阅模式编写起来可能很麻烦的，适当的proxy可以使得工作简单许多，只需要一个中间层。

proxy对应于大量的发布，这样，数据的缓慢变换也几乎相对不存在了，所以，poll未尝不是好的选择，而通知机制，带来的资源紧张就反而严重了。
至于数据的疯狂变换，可以改进你的poll，一次poll可以获取多条信息或加入优先，也就不存在重要信息滞后了。

当然，其实也就是一个混合方式了（因为模式只是一个纯洁的抽象，个人意见），总的思路是proxy＋poll。

# to 清风雨:

这个问题需要考虑应用的场景：如果数据不是那么重要，允许丢失一些中间状态，那轮询就可以。如果数据非要不可，而且对处理时间还有严格的要求，那就只能用发布-订阅模式了。你说的优先级也是有可能采用的，在发布订阅模式中加入优先级，根据情况甚至可能抛弃掉一些不重要的数据。

在我习惯的设计中，发布-订阅模式不会到处使用，往往只存在一个。我不了解java,不明白为什么会有大量的发布订阅模式？