演示模型与MVP（被动视图）
我试图学习演示模型模式，并且在我的尝试中，我对演示模型和MVP - 被动视图的区别感到困惑。 特别是当Presentation Model执行同步而不是View时。 这个问题是对这个问题上一个问题的扩展。
Martin Fowler提供了演示模型在文章中进行同步的可能性。
引用视图的Presentation Model通常在Presentation Model中维护同步代码。 由此产生的观点是非常愚蠢的。 该视图包含任何动态状态的setter，并响应用户操作引发事件。 这些视图实现了在测试演示模型时允许轻松存根的接口。 演示模型将通过更改任何适当的状态并重新加载整个视图来观察视图并响应事件。 因此，无需实际的UI类即可轻松测试同步代码。
如果Presentation Model正在同步，我不完全理解它与MVP（被动视图）的不同之处。 他关于被动视图的文章显示了一个使用同步更新视图的示例。
因此，演示模型引用视图（和同步）的演示模型模式与MVP（被动视图）相同吗？
Model-View-Presenter是一种体系结构模式，它在UI级别定义行为和逻辑的结构。 MVP将演示的逻辑（例如与后端服务和业务层交互）从显示按钮和界面组件的机制中分离出来。
被动视图是模型 - 视图 - 演示者模式的一个子集。 基本模型视图演示者图
从外部看，被动视图的架构看起来像这样：
UI – The User Interface reflects what is going on beneath it by implementing one or more View interfaces
Presenter – The Presenter receives interactions from the UI or Model and updates the Views it is attached to
Model – The model is a facade or black box in our diagram, behind which is a business logic layer and data layer
在一个扁平的体系结构中，我们将从接口收集数据，也许做一些业务和数据验证，然后使用存储过程或内联SQL将其直接保存到数据库中。 定义一个数据访问层（或像实体框架这样的数据模型）可以使我们的应用程序在对应用程序有意义并且一致地存储和检索的有凝聚力的，定义的对象上运行。 定义业务逻辑层使我们能够以与业务一致并且在应用程序内部保持一致的方式集中操作应用程序中实体的业务规则，从而最大限度地降低业务流更改时发生的风险。 分离填充输入的逻辑和响应用户界面上的按钮按压从传递给最终用户的信息以及对其输入的概念性响应，允许系统通过任意数量的接口一致地与用户交互进入相同的应用程序。
我的示例应用程序有几个功能和非功能需求：
Functional – Display product number, name, list price, and available quantity in tabular format
Functional – Provide a basic search input and button to search product names
Non-Functional – Implement an M-V-P pattern – Obviously the purpose of this whole exercise
Non-Functional – Use a simple model stack that can be easily replaced with a Service-Oriented one at a later time
Non-Functional – Build with the idea that we will later create a Silverlight or WPF front-end
Non-Functional – Make pretty pictures for article
上一篇: Presentation Model vs MVP (Passive View)
下一篇: MVP and model