在C#中分离UI和逻辑

And*_*ndy 14 c# user-interface business-logic code-separation

有没有人有任何关于保持我的GUI类逻辑的建议?我尝试使用良好的类设计并保持尽可能多的分离,但我的Form类通常最终会混入比我想要的更多的非UI内容,并且它往往使维护变得非常痛苦.

(Visual Studio 2008 Professional,C#,Windows应用程序).

非常感谢.

Chr*_*isW 14

把你的逻辑放在一个单独的程序集中 并且,构建组件没有它的引用任何GUI封装(例如System.Drawing,System.Windows.Forms等).


Dav*_*vid 7

这只是一个练习和自律的问题.我的意思是,我们都做到了.我们都会在错误的条件下不断地做这件事(经理/客户大喊大叫"现在"和"正确"等等).

编写代码来驱动UI时我做的一件事(更多在网络方面,但同样的事情适用)是问自己每个代码单元(单行,条件,循环等)是否该片代码取决于UI的存在.如果我正在写一个文本框,那是依赖于UI的,所以它就在那里.但是,如果我正在计算将在该文本框中的结果,那可能是业务逻辑.

另一种方法(正如ChrisW在我输入时提到的那样)是在非UI类库中首先开发逻辑.尽可能多地使用逻辑(使用您对不依赖于基于UI的库的定义"逻辑"的判断).然后构建UI以利用该逻辑.有两种不同的方法可以同时开发这两个部分,例如在接口类后面删除逻辑程序集,只是将UI部分编码到那些接口(然后使用依赖注入将程序集类插入接口)等.


Chr*_*isF 5

您需要研究以下设计模式:

网站经常使用的模型-视图-控制器(MVC) (ASP.NET) WPF 经常使用的
模型-视图-视图模型(MVVM)

通过保持其中之一,您应该能够将应用程序的各个部分分开。

还有其他模式可以完成类似的工作。

此外,使用 WPF 进行开发会有所帮助,因为 UI 是由 XAML 定义的,并且执行工作的代码是 C#。这可以提供基本程度的分离。如果您发现自己编写的 C# 代码只是操作 UI,您可以退后一步思考“我应该在 XAML 中执行此操作吗?”。显然,您可能需要在后面的代码中做一些事情,但这是一个开始。


Mat*_*sca 5

3 层架构正是您所需要的。

您构建了 2 个可重用层:

  • 数据访问层 (DAL),仅包含从数据库读取/写入所需的代码
  • 使用 DAL 的业务逻辑层 (BLL),包含业务规则、验证,并为 UI 提供外观以供使用

然后在您的 UI 项目中,您引用可重用层并仅处理 UI 特定的内容。UI 项目仅与 BLL 对话,与 DAL 没有直接连接:

UI <---> BLL <---> DAL

如果您想支持多种数据库类型,您可以拥有多个使用可重用组件的 UI 层,以及多个可互换的 DAL。