5月 28 日消息,人人网近日发布 Windows Phone 2.0 版本客户端,新增桌面快捷方式及视频播放等功能,并对多项功能进行了程序优化,全面提升用户的交互体验。  新版客户端采用了全新的 UI 设计,轻点“+”号即可一键完成新鲜事评论、分享和收藏,操作更加方便流畅;在新鲜事中,增加了视频浏览功能,点击即可进入浏览器观看视频,感受与网页版一致的社交体验。  根据 Windows Phone 的特性,人人客户端设置了好友分组和字母快捷索引,查找好友更方便。当长按某个好友时,就可以给 TA 留言,并在翻转后显示最新状态,不再错过朋友的任何一条动态。另外值得一提的是,用户可以添加桌面快捷方式,将“发状态”和“拍照上传”两大功能固定至手机桌面,一键发布新鲜事。  根据最新一组数据显示,人人网在移动互联网领域增速明显,每天有 55% 的用户通过移动设备登录,其中超过 75% 为智能手机用户。业内人士认为,人人网 Windows Phone 客户端的升级不仅进一步完善了人人在无线平台的布局,还将对移动用户的增长起到推波助澜的作用。  人人网 Windows Phone 2.0 版客户端主要功能介绍:  1. 全新的 UI 设计,精致简洁,交互流畅;  2. 支持公共主页和视频类型的新鲜事,更多内容更加精彩;  3. 加入 Windows Phone 特有的分组和字母索引功能,查找好友更方便;  4. 固定“发状态”和“拍照上传”到桌面,一键发布新鲜事;  5. 缓存浏览新鲜事和好友头像,

  我曾经作为一个普通消费者使用过 Android 设备很长一段时间,也一直感叹它的强大与便利。而我有机会接触 iOS 设备之后,却更是为 iOS 系统的灵巧、便利和美观惊叹。运行同样的应用, iOS 设备总是显得更为灵动和友好。 iOS 设备无比迅捷的响应能力更是令我印象深刻,据称这是由于系统界面绘制时,图形进程优先级别不同造成的。  而作为一个刚刚入门的 Android 开发者,我最近阅读了许多 Android 应用的开发指导与规范,也确实按照这些规范开发了几个 Android 应用,但却感到越来越不是滋味。虽然这些指导与规范十分合理与明确,但很明显,许多现有的 Android 应用不知为何都没有遵守它们。我自己每天使用的 Android 设备上虽然安装了近百个应用,但真正称的上“规范”的却寥寥无几。这使我意识到,很多时候,运行 Android 系统的设备虽然存在一些固有的缺陷,但更多时候糟糕的应用才是造成用户体验不佳的罪魁祸首。    如果用通俗易懂的语言来描述, Android 应用的标准生命周期正式开始于被启动并显示应用界面,此后只要用户没有离开应用界面,那么这个应用将始终处于“可见”阶段。换言之,一旦用户通过什么操作从当前应用中跳出,那么这个应用将进入下一个阶段,这个阶段被称为“后台”阶段。离开当前应用的方式有很多种,可能是当前应用启动了另外一个应用,也可能是用户通过“返回”或者“主界面”按钮主动离开了应用。在处于“后台”阶段的应用可以随时回到“活动”阶段——只要用户通过任务管理器或者任何别的方式重新启动了它。处于“后台”阶段的应用也通常可能会因为内存不足被终止。  由于处于“后台”阶段的应用可能会被不可预期的终止,Android 允许应用在切换到后台时一定会有机会对当前数据进行保存。不过与此同时,处于“后台”阶段的应用被终止时其实也有机会保存数据,但这个保存机会是否存在取决于系统内存的紧张程度。  因此,通常建议 Android 开发者在应用切换到“后台”阶段时保存对用户来说十分重要的数据,比如 Gmail 应用会在切换到“后台”时保存邮件的草稿。而那些对用户来说不那么重要的数据,比如 Gmail 应用从服务器上缓存到一半的邮件数据,建议在应用被终止时再尝试保存,因为它们可以随时从服务器上重新拉取,丢了也无关紧要,何况他们相对更为庞大,容易在进行保存操作时拖累系统效能。  但我在操作调试器监视自己的 Android 设备时,却注意到一些内置了广告服务的应用,尤其是游戏应用,会在切换到“后台”时会尝试保存从服务器上获取到的广告图片。这些图片数据不仅很大,而且数量也不算少,导致游戏切换到主界面时速度很慢,降低了用户的操作体验。这么做的原因也不是不能理解:这些应用无论如何都希望在你没有网络连接时向你展示广告。  而在 iOS 系统上,应用被切换到后台时也有机会执行操作。但系统和用户随时都可以强行结束应用,这种情况下应用没有机会执行任何操作。这也使得很多开发者更小心地处理自己的应用,以免因占用资源太多被系统关闭,而不会出现 Android 上那种肆无忌惮的做法。  值得一提的 Google 官方指导完全没有做这方面的限制和要求, Google Play 也没有因此对应用进行下架。    iOS 上由于没有文件系统,且对应用产生的缓存和用户数据都有非常苛刻的存储规范,否则就会被苹果公司下架,因此应用对于存储数据的位置十分统一。  但在 Android 上,这简直就是一场灾难。获取大容量存储器读写权限之后,很多应用都会在其根目录中生成缓存文件。除了上文提到的广告,这些文件甚至可能是应用程序用于存储自身状态的。因为有些应用希望在被卸载重新安装后仍能找回先前的配置。但这也造成很多问题。首先这给用户管理存储器带来了巨大的不便:要如何处理这些自己冒出来的文件?其次这种行为也无故减少了存储器的可用容量:如果用户再也不打算安装这个应用了怎么办?  事实上,Android 系统已经设计了可用于应用存储内部数据的几种方式。除了机身内部对应的数据文件,如果应用确有必要,也可以在大容量存储器的 Android/Data 位置存储数据,这些数据也能在应用卸载时一并被 Android 系统自动删除。不过许多开发者对此完全不在意,仍然肆无忌惮的在用户存储器内生成各种文件。某著名新闻客户端生成的存储文件甚至会给用户造成严重困扰,使用户相册无故出现不相干的图片。因为其缓存文件夹没有遵守命名规范,在文件夹名前加“.”或者在文件夹内放置 .nomedia 文件以防止媒体扫描应用搜索。另一款著名即时通讯软件更是夸张,竟然同时生成两个文件夹缓存数据。  Google 官方指导同样没有在这方面提出限制和要求,只是简单解释了几种数据存储方式的用法和用例。    相信很多朋友看到这里第一个反应是: Android 有应用交互界面规范吗?遗憾的是, Android 2.3 之前的确是没有明确的应用交互界面规范。但在 Android 系统来到 4.0 之后, Google 终于意识到应用交互界面的规范化有多么的重要,因此推出了基于 Holo 主题的应用交互指导。现在,包括淘宝,人人和一众 Google 自己的应用已经依照新规范重新开发,它们看上去兼具美感和实用性。但也有一些应用刚愎自用,甚至照搬 iOS 系统上的界面。希望未来它们能够有所改变,给用户带来更好的体验。  除了上文提到的 Android 应用普遍存在一些问题, Android 上的一些著名应用不守规矩的行为更是夸张,比如某款著名通讯录应用就会尝试将自己的短信接受优先级别设置成比系统应用还高,一度导致了 Android 防病毒程序 Dr.Web 报告病毒。还有一款网盘应用更是夸张,关联了 Android 系统内所有可以注册的文件类型,导致用户打开任何文件时都会被询问“是否要上传到网盘?”这些问题的具体细节太过复杂,在此略过不表。  总体上来说, Android 是一个自由的系统。就连 Google 官方指导也都弥漫着这种气息。它很少告诉你“要怎么做”,而是一直不停的解释“能怎么做”。比方说,应用图标的形状以及风格完全不受限制。或许 Google 认为圆角矩形的磁贴风格并不是设计师唯一的选择。Google 也没有强制开发者必须使用 云端数据备份接口。更没有强调 是应用程序接受推送数据的唯一方式。就连 主题风格也仅仅是推荐开发者采用,并没将不符合规范的应用从 Google Play 下架。  有评论认为 Google 太过仁慈而导致应用程序总会有些不守规矩的小动作,但我认为自由和开放不能因此而受到影响。更多时候,还是希望开发者能够仔细研究自己的程序可能造成的问题,不要怎么方便怎么来,多从用户的考虑角度一下。

图为美丽说无线产品负责人胡嵩    必须关注用户产品体验的每一个细节,然后迅速作出反应,这是电商导购美丽说无线端在做完产品运营的一大感受。  2011年 11 月 19 日,晚上7:40分,北京新中关大厦美丽说办公室。  面对一用户反映美丽说 iPhone 版浪费流量问题,美丽说无线产品负责人胡嵩在微博上第一时间和该用户进行了沟通:“我们已经在最新提交 App store 的版本里面改进,会识别您的网络环境自动切换至省流量模式。对于您本次消耗的巨额流量,您可以私信告知电话号码,我们会为您充值 30 元作为补偿。”  这只是美丽说无线端运营的一个细节。在国外 Pinterest 模式日益火爆的当下,作为 Pinterest 模式在国内的一大变种,美丽说的无线端运营经验对于后入局者无疑有着一定的借鉴意义。    定位理论之父艾·里斯曾经说过:品牌是根橡皮筋,你多舒展一个品种,它就多一份疲弱。而美丽说无线端产品在起初的产品功能定位中也走了同样的弯路:  2011年 3 月,美丽说在传统的 PC 端已经稳步发展,其开始开发无线客户端,延伸产业链条。美丽说无线端的第一版基于 webkit 内核,用 html5 开发,尝试跨平台解决方案。在具体的产品页面设计上,美丽说客户端早期的版本包括“我的关注、热门、分享、一起拍、找闺蜜”等内容组成部分。  而如今美丽说无线端已经将拍照、找闺蜜等功能砍掉,并选择性使用 html5。  “最开始的时候,研发能力不强,我们采用 html5,希望能跨平台,节省成本。但后来的产品推出后才发现 html5 不成熟,很多交互,如调用摄像头读取文件、手势识别等 html5 并不支持。”胡嵩刚开始就陷入了困境。  后来,美丽说无线端开发团队,采取将 html5 和本地代码结合的方式,运营性的内容用 html5 做,非运营的则采用本地代码做。而这也成为目前很多移动 App 的研发制作策略。  胡嵩说,最开始做产品,都想满足用户的所有需求,但一款好的移动产品却相反,需要在功能定位上做减法。“一定要弄清楚用户的核心需求。”  美丽说无线端开始就做了“一起拍”的拍照功能。这一想法,最初起源于国外的 Instagram。“2011年初,我们就研究 Instagram。我们认为女性爱臭美,有图像采集的需求,大家互相晒,可形成社区关系。后来运营证明,拍照确实能每天为美丽说贡献图片数量,最高峰每天1-2万张,但却没形成社区。”  而在美丽说无线端的“找闺蜜”功能推出时,完全是研发团队臆想的用户需求。“我们认为用户有闺蜜在这里,就可以和闺蜜一起逛,用户体验更爽。但现实的移动应用端,女性对此并没有太多需求。这一功能需要设定某一场景,然后引导用户去发现,单纯的找闺蜜就显得生硬。”  为此,美丽说无线端将“找闺蜜”的首页位置取消,而选择深埋在其他功能,在一个合适的场景推出来,功能保留,让用户最需求的时候推送给用户。  现实中,有导购社区添加了比价的功能。对此,胡嵩认为,比价将导致购物环节被打断,挑喜欢变成了挑价格便宜,本身的产业链条就被扭曲了。  眼下,整个女性导购社区除了美丽说之外,活跃在第一阵营的还有蘑菇街,后者也推出了无线端。对于在行业内对用户的定位,胡嵩认可此前媒体的归纳:美丽说定位都市白领;蘑菇街定位 90 后小女生;美丽说做垂直微博,注重内容运营;蘑菇街注重导购和交易的达成。    国内整个移动互联网的平台格局,2007年前后基本是 symbian 平台,此后数年无竞争,2009-2010 Wap 版依然占据主流,2011年则成为基于 iPhone 的 iOS 系统和谷歌 Android 系统的天下。而眼下,微软 wp 平台的势力也杀入进来。  移动互联网的创业决不同于很多年前的互联网创业,他们必须清晰的意识到巨头们的战略格局,否则将被截杀在摇篮中。  对于平台选择,胡嵩认为,女性导购社区必需先布局 iOS 平台。“Android 上最困难在于屏幕的尺寸、色差等不规范,而且 Android 本身的版本也各不相同。而 iOS 用户群更有典型,时尚从上到下,所以偏重时尚的女性导购应该先做 iPhone 端,然后调整。但对于一些通用的工具类应用,则要先做 Android 平台。  概括起来,包含导购社区无线端的用户数据包含以下几大规律:  第一,几种平台终端用户中,WAP 端用户小白多,看到便宜东西容易冲动消费;iPhone 用户消费能力强,对价格不太敏感;Android 用户最抠门,消费不多,但广告点击率却是 iOS 的几倍——啥都好奇,啥都试试,就是不买单。  第二,女性导购类社区需要立足高端机型,iPad 购买力最强,低端机型的屏幕体验很难做好。  第三,在用户构成上,使用 2000 元以上机型的用户占据 80%,iOS 用户和安卓上相近,但前者的总收入是后者2-2.5倍。  第四,具体用户数据分享中,用户最喜欢的动作是“喜欢”,收藏起来自己欣赏,日均达到百万次,但利他的“分享”则少有人做。  此前,蘑菇街内部人士曾披露,22% 的用户为真实可信,其中只有3% 是靠谱的有质量的分享。而胡嵩则透露,美丽说上真实可信的近 50%。最开始,为了刺激用户分享积极性,美丽说付可观的费用给专门的达人,来涌动分享。但用户增量达到一定阶段后,则砍掉这一成本。  现实中,很多移动互联网领域的创业者一直为推广而发愁。胡嵩说美丽说 iOS 的正式版本发展迅速,很大程度上得益于苹果的推荐。  一款产品如何才能获得苹果的推荐?“设计要精良,符合品质感,苹果特看重设计,新上的应用容易推荐,模仿的则很难。”胡嵩如此强调。  此外,胡嵩甚至利用个人微博未美丽说的客户端做营销。“我送你们每人五元话费啦~~现在用 iPhone 下载美丽说客户端,注册美丽说,输入我的手机号,可以得到 5 块钱!”2011年 11 月,胡嵩在微博中如此写道。    据截止到今年 3 月份的数据显示,美丽说宣称其移动客户端装机量达到 600 万,日活跃量超过 60 万,移动客户端每天为淘宝带去订单 100 万元。  如何打造出一个优秀的产品经理,让产品迅速俘获用户?  胡嵩总结道:需要放下专业的高姿态,把用户当成白痴一样去考究,产品上市前,先找一两个不相关的产品经理来为产品挑刺,然后再修改,快速迭代。具体设计的要领,胡嵩认为,美丽说移动客户端设计原则有二:其一,一个 APP 只做一件事情,其二,让用户达到想要的内容不超过三步。  胡嵩说:“2G 时代大家比拼的是内容的帅选和过滤,随着移动互联网的速度提升,还要拼技术,比拼谁的响应速度更快。”  此前有业内人士披露,iOS 客户端一个广告点击费用3-5毛钱,从点击到下载转化率约1.5%,从下载到激活的转化率 90%,从激活到注册转化率 40%,从注册到活跃转化率 50%。这意味着通过 CPC 广告获得一个活跃用户的成本至少 150 元。  对于像美丽说这类社区导购的移动 App 获得用户的具体成本,胡嵩表示,美丽说这类移动端和工具类、游戏类不一样,游戏类 cpc 转换率 10%,3元钱获得一个用户,大众点评5%,而美丽说这类在1-2%。  值得一提的是,目前,除了服装领域,包括零食、家居等领域,出现了各类“美丽说”的模式。  究竟这类垂直的类“美丽说”能否走向成功。胡嵩没有给出确切答案。但他认为,这类垂直的导购,商品类别必须足够丰富,并且可以形成交易的闭环。前提是必须准确找到用户使用的场景,从而确定产品方向。  “女性时尚类最接近,一些食品类、汽车类,因为图片本身难以表达内容,且需求的频次较低,我不看好它的明天。”在胡嵩看来,玩具领域倒是存在着机会。(完)    1、腾讯科技:如果后来者做类似美丽说等社区导购的手机端版本时,如何选择不同的平台?  胡嵩:美丽说无线端因为做女性类的导购,需要先做 iPhone 上的 iOS 应用端,然后调整。iOS 用户群更典型,更符合时尚的定位。时尚是从上到下,所以先 iphone。而对于一些通用性的移动应用,则需要先立足 Android 平台。  2、腾讯科技:如何有效推广一款无线端产品?  胡嵩:现在刷屏等方法已经不再灵验,美丽说无线端用户迅速增长,主要是 iOS 版本,得到了苹果的推荐。移动互联网产品的设计要精良,因为苹果特看重设计,一些符合品质感,创新型的新应用容易被推荐,模仿的很难。  3、腾讯科技:美丽说这类社区导购的移动 App 获得用户的成本是多少?  胡嵩:美丽说这类移动端和工具类、游戏类不一样,他们的 cpc 转换率 10%,3元钱获得一个用户,大众点评5%,而美丽说这类在1-2%。

  相比市面上昂贵的 Windows Phone 机型,Lumia 610 绝对是性价比超高的一款:不仅为用户带来原汁原味的 WP Tango 体验,更重要的是价格相当实惠。目前该机已经于亚洲全面上市,而作为促销攻略,诺基亚官方又出炉了最新的高清官方照。  从最新官方照来看,Lumia 610 外观设计非常精致,而且会有四个颜色可选。当然,最引人注意的莫过于其内置的 800MHz 处理器以及 256MB RAM 了。

  我们所开发的应用程序大多都需要提供一个图形用户界面(GUI)。关于 GUI 应用的架构设计, 已经有了很多模式, 比如 Martin Fowler 的 blog 中有一篇"“, 里面介绍了 Form & Control、MVC、MVP、Passive View、Presentation Model、 Supervising Controller、Event Aggregator, Observer Synchronization 等多种模式。模式可以帮助我们建立优雅的架构, 但前提是弄清楚模式的应用场景。这些模式自然不是凭空产生的, 都是为了解决具体的问题. 模式在实现上的差别, 通常都体现了在约束间的不同取舍, 以及问题的差别. 弄清楚 GUI 应用面临的设计上的问题, 有助于我们正确的挑选设计方案. 下面我们来看一些 GUI 应用常见的设计问题。  第一个问题就是界面的变化和业务的变化频率不同, 通常是界面变化更频繁, 而我们希望一方的变化不至于影响另一方的逻辑. 对于这个问题, 一个自然的解决方案就是分离界面显示逻辑和后台业务逻辑. MVC 和 MVP 都涉及到了这一点, 它们的共同特点就是把 View 和应用程序的其它部分分开了. 这是一个关键的分离, 从此之后应用被分为两部分, 抛开它们彼此可以独立的变化不说. 最大的好处是这两部分的问题也可以分而治之。应用程序的其它部分有自己的问题和方案, 不在我们讨论范围内. 我们后面将聚焦在 View 和相关的显示逻辑方面的问题.  当然这种分离也不是没有代价的, 一个立即的问题就是 View 如何更新. MVC 和 MVP 把 View 分出来制造了这个问题, 它们也同时提供了手段解决这个问题。MVP 中 Presenter 完成业务逻辑后可以拿到最新的 Model, 它可以操控视图, 根据最新的 Model 来设置视图的各种属性并刷新。MVC 中 Controller 在完成业务逻辑操作后更新 Model, Model 变化时可以发出事件, View 订阅 Model 更新事件来更新自己。MVC 有各种变体, 一种是 Controller 直接把 Model 推给 View, View 自己从 Model 中取出感兴趣的数据来刷新自己。  对视图更新的处理是 MVC 和 MVP 在实现上的主要区别: MVP 中 View 不需要知道 Model, Presenter 直接操作 View。MVC 中 View 知道 Model, 自己根据 Model 来更新自己的状态。  (图片来自: )  跟 View 相关的另一个常见问题就是可测试性. 即使其它分出去的部分可以独立测试, 但剩下来的 View 依然 Hold 住了一部分显示相关的逻辑. 显示逻辑也是逻辑, 也需要测试, 而通常直接测试 GUI 界面是相对难以测试的. 现有直接测试 GUI 的测试工具都面临以下问题:测试耗时长, 因为要启动真实的应用测试比较脆弱, 无论是可靠性还是可维护性, 因为界面元素的变化很频繁, 而通过编程来控制界面和用户真实操作经常有细微的差别, 尤其是时序相关的问题  一个思路就是把显示逻辑从 View 中分离, 让 View 退化为简单的 GUI 控件的容器. MVP 做出了最初的努力, 而另外两个模式更加强调了这一点: 和 。Passive View 针对可测试性的方案是把所有的显示逻辑都从 View 中移除, View 不再依赖任何 Model, 只是提供接口完全被动的由 Controller 或者 Presenter 来设置显示所需数据并刷新。Presentation Model 则封装了 Domain Model 拥有的数据到 View 显示所需数据之间的映射。 View 不再需要与 Domain Model 打交道自己来把业务数据转换成显示需要的数据, View 只需从 Presentation Model 中取数据, 映射逻辑都在 Presentation Model 中。 而 View 所需数据和 Presentation Model 是简单的一一对应关系。  我们上面讨论的都是相对简单的 GUI, 比如我们其实假定了 View 和 Model 的一一对应, 甚至也假定了应用只有一个 View。 然而我们还有多视图的情况。 多视图带来了以下问题:当 Model 变化时如何保持多个视图间的一致性多个视图间的交互的可控性事件的循环触发问题  Martin Fowler blog 中描述的 和 为当 Model 变化时刷新多个视图提供了两种方式, 分别应对不同的情况。Flow Synchronization 在 Model 变化后的某些明确定义的时机明确的更新所有受影响的 View。 它的优点是显式, 直观, 可控, 缺点是很容易造成多个 View 之间彼此有依赖, 不易扩展, 因此它适用于视图较少的情况Observer Synchronization 则是让多个 View 都订阅 Model 的更新事件。 这是 Observer 模式在同步方面的应用, 具有 Observer 松耦合的特点。 缺点也不意外, 它让用户交互的影响变的隐式了, 不易于理解应用整体行为和开发时调试等。  传统上还有一种用于解决交互的可控性并让 View 之间彼此解耦的模式, 就是 Mediator。 当我们在应用 Flow Synchronization 时, 如果把 View 之间的交互都抽取到一个中介者对象里面, 每个 View 都不知道其它 View, 只知道中介者对象, 当有事件发生时, 由中介者对象来更新 Model 和其它 View, 则我们可以获得相对清晰的交互和相对松散的耦合。 来看一下<<设计模式>>里面对 Mediator 的描述:  意图:  适用性:  效果:  多视图的另一个问题就是事件的循环触发问题。 场景如下:事件A发生->事件A处理函数->处理过程中触发了事件B->事件B处理函数->处理过程中又触发了事件A->……一个简单的例子比如界面上有两个文本框, 要保证它们的和一直都是 100。 比如文本框A输入 30 的时候, 文本框B要显示 70。 文本框B输入 40 的时候, 文本框A要显示 60。 我们在处理第一个输入事件的时候需要设置第二个文本框的值, 而这个设值动作会触发第二个文本框的事件处理, 它也要设置第一个文本框的值……如此循环。  通常的处理方式有几种, 目的都相同:尽量减少不必要的事件发送状态真正改变时才发事件, 状态没有改变的话就不发事件。 上面例子中的 TextBox 控件。 如果连续用相同的参数调用其 SetText, 除了第一个调用可能会触发 TextChanged 事件外, 后续的操作都不会触发, 因其 Text 并未真的改变。 在我们的领域模型中触发事件可以遵循相同的 Pattern避免重入。 当事件处理函数开始事件处理的时候, 把自己置成一个不同的状态, 比如"处理中", 事件处理结束的时候再置回正常状态。 当在事件处理过程中触发新的事件又导致事件处理函数被调用, 可以检查自己是否在"处理中"的状态, 如果是的话忽略即可。根据事件的源头来决定是否处理。 这需要在事件的上下文中加入额外信息, 比如事件的发送者 sender。 微软的 CAB 框架允许指定事件的 Scope, 这样处理函数可以只处理自己感兴趣范围内的事件。严格遵循 CQRS 原则, 更新 Model 的函数和刷新视图的函数应该是两个函数, 分别是对用户输入事件的响应和 Model 改变事件的响应。 这样刷新视图不会再引入新的事件, 减少循环的几率。使用细粒度的事件。 粒度过粗会引发不必要的响应, 增加循环的可能  谈到事件的粒度, 过细的粒度会引起另外一个问题:注册事件处理函数太繁琐, 不易看清交互。  可以来解决这个问题。    最后回过头来看一下已有的几个模式各自的重点 :  其中:MVP 比 MVC 更强调显示逻辑跟视图的分离。MVP, Presentation Model 和 Passive View 都强调视图跟显示逻辑的分离, 程度不同: MVP 引入这一分离, Passive View 分离的最彻底最可测, Presentation Model 介于两者之间。Presentation Model 比 MVP 和 Passive View 更强调的是为显示逻辑创建单独的 Model, 而不是依赖于 Domain Model。  更全面的比较, 请参见老马的"“, 及里面的链接。

分类:兴趣

时间:2016-09-09 02:05:14