c# architecture: 可视化组件的功能答案

【问题标题】：c# architectural: functionality of a visual componentc# architecture: 可视化组件的功能
【发布时间】：2015-08-07 22:47:32
【问题描述】：

我有一种感觉，我正在把我的组件变成一个大泥球，因为我没有正确构建这种应用程序的经验（更习惯于数据库应用程序堆栈）。

我正在编写类似于可视化编辑器的程序 - 基本上，一些图形背景可以导航（缩放/平移），在其上添加一些对象并对其进行操作 - 移动它们，删除，分别移动每个对象的各种元素，等等。

它在结构上是一个视觉组件（源自相当通用的东西）。它包含对项目模型的引用，该模型代表编辑器操作的数据方面的所有内容。此外，还有许多管理人员实施了项目数据可能发生的事情和发生的事情的逻辑，以响应用户的操作。到目前为止一切顺利。

组件本身还有许多属性和事件，它们实现了用户交互的特殊性。例如，渲染背景、渲染其上的所有对象、使用控制元素（拖动手柄等）修饰选定对象。

现在的问题是：图形实现和与用户交互的这些细节 - 有什么比将所有这些代码集中在组件类中更好的方法？我想到了几个选择：

维护一个包含所有内容的大型组件类，可能同时将其分成几个部分类以这样分离职责。
将渲染和交互逻辑实现到单独的类似管理器的类中，并将组件的实例作为参数传递 - ??? - 不知何故，经理需要了解很多关于组件状态的信息，这就是问题所在。那里的许多属性本质上是私有的，并且对 WinForms 应用程序的其余部分不可见。所以这是一个问题......

有什么建议吗？

【问题讨论】：

3 - 输入ElementHost 并使用 WPF，它支持 DataBinding 并允许您正确分离 UI 和数据，允许更高级别的自定义并且不需要winforms 可以做任何事情，例如“所有者抽奖”。
UI 和数据在我的情况下被正确分离。数据以及由于用户交互而发生的变化——我很满意。我有一个复杂的自定义编辑器，只想知道如何更好地构建它的逻辑。不确定我们是否在谈论相同的问题，HighCore。无论如何感谢您的意见。
我真的很难说出你在这里发生了什么......也就是说，#1 应该提出一个很大的危险信号，一般来说，最好有很多小班比较大的。部分类不分离职责，只是代码的文件位置。你还剩下一个可能做得太多的大型班级。至于＃2，您可以将组件作为参数传递，并且仍然具有私有属性......如果管理器类需要知道一些信息并对其采取行动，它真的应该是私有的吗？
来自现场：我在这里尝试第二种方法，基本上将表示逻辑提取到以组件为参数的管理器类中，它实际上看起来很性感。我的目标是让控件本身只维护状态，为主机表单提供 API 并调度与用户的交互。复杂的绘图和处理编辑操作（点击级别）将在管理器之外。

【解决方案1】：

我不会使用单独的类和传递东西，只是以防止出现巨大的代码文件。

您提到您的组件引用了项目模型 - 您可以将视觉特征定义为控件，并拥有一个 DTO 类型的类，您可以用需要显示的数据填充。这将与其他 WinForms 组件一致；例如 ListViewItems 用于 ListView 控件。

或者，您可以将上面创建的控件子类化，并将对模型的引用放在那里。

否则，如果你真的要创建一个巨大的类，我会更喜欢名称清晰的部分类（MyComponent_Events.cs 等），而不是一个巨大的滚轮杀手。

【讨论】：

嗯，显然，这不仅仅是为了争夺代码的大小。实现一些“可测试性”也是一个目标。目前我什至不知道如何通过单元测试来处理这段代码（它被认为是实验/头脑风暴的一部分，所以在这个特定领域还没有 TDD）
对控件的可见属性进行单元测试很痛苦，所以我肯定会尝试将其与项目的其余部分隔离开来，并确保控件不引用模型。还编辑了我的答案。