oo问题 - 混合控制器逻辑和业务逻辑

时间:2009-06-10 23:27:14

标签: c# .net design-patterns oop

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

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

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

  1. “控制器”逻辑,决定需要完成什么以及何时完成。
  2. 执行需要完成的操作的实际业务逻辑(例如,执行数学运算并返回结果的控件等)。
  3. 我的问题是,OO架构是否允许将这两者都放在一个对象中?或者是否建议将它们拆分为“控制器”对象和“业务逻辑”对象?我应该参考这个设计模式吗?

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

4 个答案:

答案 0 :(得分:7)

您正在做的是一种“胖控制器”架构。目前,软件开发趋向于瘦控制器。

OO设计完全是解耦。如果你只关注OO编程的一件事,就这样吧。

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

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

答案 1 :(得分:3)

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

答案 2 :(得分:1)

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

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

答案 3 :(得分:1)

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

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