c#体系结构：可视组件的功能

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

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

它在结构上是一个可视组件（源自某种相当通用的东西）。它包含对项目模型的引用，该项目模型根据编辑器操作的数据表示所有内容。此外，还有许多管理者将项目数据可能发生的事情和实际发生的事情的逻辑作为对用户操作的响应来实现。到目前为止还不错

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

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

维护一个包含所有内容的大型组件类，同时可能将其划分为几个部分类，以这样的方式划分职责

将呈现和交互逻辑实现到单独的类似管理器的类中，并将组件实例作为参数传递-？？-不知何故，管理者需要知道很多关于组件状态的信息，这就是问题所在。那里的许多属性本质上是私有的，对于WinForms应用程序的其余部分来说没有任何可见的业务。所以这是一个问题

---

有什么建议吗？

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

您提到您的组件引用了项目模型—您可以将可视特性定义为控件，并使用需要显示的数据填充DTO类型的类。这将与其他WinForms组件保持一致；例如，

ListView

控件的

ListViewItems

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

---

否则，如果你真的最终创建了一个巨大的类，我宁愿使用名称清晰的部分类（

MyComponent\u Events.cs

etc）而不是一个巨大的滚轮杀手。

3-放置一个

ElementHost

并使用WPF，它支持数据绑定并允许用户界面和数据进行适当分离，允许更高级别的定制，并且不需要winforms所要求的可怕的黑客来做任何事情，例如“所有者绘制”。在我的例子中，UI和数据是正确分开的。数据以及由于用户交互而发生的情况-我对这些数据非常满意。我有一个复杂的自定义编辑器，只想知道如何更好地构造它的逻辑。我不确定我们在讨论同样的问题，HighCore。无论如何，谢谢你的意见。我真的很难告诉你这里发生了什么。。。也就是说，#1应该发出一个大的红旗，一般来说，有很多小班比大班好。分部类不区分责任，只区分代码的文件位置。你仍然只剩下一个很大的类，可能做得太多了。至于#2，您可以将组件作为参数传递，并且仍然具有私有属性。。。如果一个管理类需要知道一些信息并对其采取行动，那么它真的应该是私有的吗？从这个领域：我在这里尝试第二种方法，基本上是将表示逻辑提取到管理类中，这些管理类以组件为参数，实际上看起来非常性感。我的目标是让控件本身只维护状态，为宿主窗体提供API，并分派与用户的交互。而复杂的绘图和处理编辑操作（在点击级别上）将在管理者之外。显然，这不仅仅是为了与代码的大小作斗争。实现某种“可测试性”也是一个目标。目前我甚至不知道如何通过单元测试来处理这段代码（它被认为是实验/头脑风暴的一部分，所以在这个特定领域还没有TDD）单元测试控件的可见属性是一件痛苦的事情，所以我一定会尝试将其与项目的其余部分隔离开来，并确保控件未引用模型。还编辑了我的答案。