【问题标题】:oo question - mixing controller logic and business logicoo 问题 - 混合控制器逻辑和业务逻辑
【发布时间】:2010-11-01 23:49:50
【问题描述】:

我不确定我是否使用“标准”术语,但这是我正在尝试解决的基本 OO 问题。

我正在编写一个 Windows 窗体。我不想要表单事件处理程序中的逻辑,所以我只是从那里调用自定义对象。

在自定义对象处,有两组逻辑。

  1. “控制器”逻辑,它决定什么时候需要完成。
  2. 执行需要执行的操作的实际业务逻辑(例如执行数学运算并返回结果等的控件)。

我的问题是,OO 架构是否允许将这两者都放在一个对象中?还是建议将它们拆分为“控制器”对象和“业务逻辑”对象?有没有我应该参考的设计模式?

目前,我已经开始将它们组合成一个对象。这个对象有一个包含控制器逻辑的“start”方法。该方法然后根据需要调用对象的其他方法,并最终将结果返回给对象的调用者。

【问题讨论】:

    标签: c# .net design-patterns oop


    【解决方案1】:

    不,我不会将业务逻辑放在控制器中。我添加了一个注入控制器的中间服务层。让服务完成工作。控制器用于路由请求和编组响应。

    将逻辑放在干净的服务层是“面向服务的”,即使您没有使用 Web 服务或 WSDL。如果您决定更改控制器/视图技术,它还有一个额外的好处。

    【讨论】:

      【解决方案2】:

      您正在做的是一种“胖控制器”架构。如今,软件开发正朝着瘦控制器的方向发展。

      OO 设计完全是关于解耦。如果您只将 OO 编程的一件事内化,那就这样吧。

      查看“Domain-Driven Design Quickly”。这本免费的电子书简要介绍了 Eric Evans 的重要著作《领域驱动设计》中涵盖的概念。

      接受这些概念的教育应该有助于您了解如何将业务逻辑与控制器或服务层分离。

      【讨论】:

        【解决方案3】:

        一般来说,您可能应该将它们放在两个不同的对象中,但有一个限定符。如果您的项目足够小并且您的对象模型不够复杂,那么将功能组合到一个对象中可能是有意义的;但是,如果您的功能足够复杂,那么分离控制器和业务对象几乎肯定会更好。至少,设计系统时要着眼于稍后分离控制器和业务对象,如果您现在不完全分离它们。

        【讨论】:

          【解决方案4】:

          您的设计问题的答案可以是以下场景:如果您还必须为其提供 Web 客户端,您将如何设计您的应用程序。

          您的 Windows 窗体 UI 和 Web UI 都将调用相同的类和方法。那么,唯一的区别就是每个层如何填充 UI 并与其他层进行通信。

          【讨论】:

            猜你喜欢
            • 2017-08-08
            • 1970-01-01
            • 1970-01-01
            • 2011-06-08
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2010-12-15
            • 2010-12-24
            相关资源
            最近更新 更多