MVP和演示者粒度

我们在所有客户身上都使用MVP,这绝对是一次不止一次的对话。类和演示者背后的代码应该有多干净?说到这一点,我们已经选择使用粗粒度的表示方法。基本上,每个表单都有自己的演示者,并且只能使用其视图获取和设置特定表单上任何控件的属性。填充控件—例如,对数据库的调用以填充组合框位于公共服务类中。用户输入数据的任何验证都位于bo类中,任何和/或所有演示者都可以重用该类。我希望这有帮助。

在我的CAD-CAM系统中,演示者不使用用户控件。用户控件位于视图中,该视图位于实现演示者使用的视图接口的exe程序集中。

如果要显示客户列表,我将其交给具有DisplayCustomerList的视图,该视图使用显示客户列表所需的任何用户控件组合。如果多个视图以相同的方式显示客户列表,那么在exe/view程序集中,它们共享一个用于执行此操作的用户控件或类。那个班不在那个集会之外。

我们的软件适用于运行多种不同类型的金属切割机。因此,我们非常强调能够剥离UI并用完全不同的UI(对应于不同的机器)替换它。所有这些UI都引用同一组核心程序集。

层次结构如下

查看exe 演示者实施 命令程序集-命令由修改模型的演示者执行 演示者界面 模型程序集

旁边是可加载的程序集,这些程序集定义动态内容,如可以加载的文件类型、报告、切割设备驱动程序等。这些程序集实现了模型程序集中的各种接口。

我要做的一件事是,我不会为每一个对话强制一个视图演示者。如果对话框与命令紧密绑定,那么将在命令类旁边定义、创建和使用该对话框。有时,一组相关命令将共享一个对话框(例如,文件处理)。

在使用MVP时,我要问的一个基本问题是,“如果想用其他东西完全替换表单,会发生什么?”。该问题的答案将确定您在哪里过于依赖特定的用户控件或表单引擎。

我的设置最大的问题(还有一个我没有很好的答案)是,当前的IDES和Langauges使得将用户控件与数据库记录联系起来变得非常容易。与其他设置相比,它的生产效率非常高,它往往主导设计。在我的cad-cam应用程序中,我不需要太多地处理这个问题,所以除了将数据集传递给视图并让它处理之外,我没有其他答案。 This site 在这种情况下可能会用到一些模式。