【问题标题】:Which pattern to choose?选择哪种模式?
【发布时间】:2013-09-18 13:57:35
【问题描述】:

我正在开发一个处理发票的桌面 GUI (Qt+Python) 应用程序。到目前为止,我得到了 2 种对象:

  • 描述发票、产品、客户(即模型)的 ORM 类。

  • 允许浏览\编辑模型的视图。

每个模型可以有多个视图。

我得到了这些类型的代码:

  1. 初始化模型的代码(“创建新发票时, 发票日期应为今天”)
  2. 对视图中的用户更改做出反应的代码(“当客户 选择,设置适当的价格水平并重新计算所有价格和 金额”)
  3. 即时进行明显验证的代码(“发票日期不能 空的!必须选择一个产品!”)
  4. 根据业务规则验证发票的代码(“产品 没有库存”、“销售额超出客户信用”)。

所以问题是——我应该选择哪种设计模式?目的是避免代码重复并允许对模型和视图进行快速更改。 到目前为止,我一直在考虑简单的模型视图方法,其中 1&4 属于模型本身。但是 2&3 让我停下来。我应该使用 MVC 并将 2&3 放入控制器吗?有什么想法吗?谢谢!

【问题讨论】:

    标签: architecture


    【解决方案1】:

    我认为查看命令查询职责分离 (CQRS) 模式对您很有价值:http://martinfowler.com/bliki/CQRS.html

    您有作为视图的模型和作为实体的模型。你的视图模型逻辑不应该被传送到控制器中,控制器应该向它分派事件。

    因此,在您的示例 #2 中,您说:选择客户时,设置适当的价格水平并重新计算...被“选择”的客户是某个域对象的一部分,无论是“订单”还是“交易”之类的。这个域对象可能不是 Order 实体,而是 OrderProcess 域视图,它有一堆与之关联的“视图”(如价目表)。

    【讨论】:

    • 谢谢,我已阅读。 AFAIU,这种模式建议引入第二个模型,该模型的任务是验证\执行 BR 等,让第一个模型从数据库中读取数据。也许我遗漏了一些东西,但这对我的场景有什么好处?并不是我的阅读功能复杂到需要单独的模型。
    • 好的,那么“重新计算的价目表”是否只是数据库中的实体列表?那里存在某种领域模型,当客户选择的操作从控制器进入时,该领域模型应该决定哪些实体需要更新。
    • Model != 数据库实体,它可以,但它通常比这更复杂。
    • 哦,我觉得我缺乏支持这个讨论所需的理论基础......我得去对这个主题进行更多的教育。感谢您的回复!
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2013-07-17
    • 2016-12-13
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-07-23
    • 2015-08-15
    相关资源
    最近更新 更多