c# - 产品配置器难以依存地管理数据/项目

Question

我正在解析一些包含对象信息的字符串，这些信息具有对象的某些依赖性或要求。

这是用于产品配置的，而对象是构成产品构建的组件。想一想，当您遍历列表来制造汽车，计算机或其他任何具有需要您选择某些组件才能获取其他组件的组件时。这是我尝试在应用程序中创建的逻辑。

我的应用程序为用户提供了一个treeView组件，其中包含从excel文件加载的对象列表。我试图创建一个对象的交互式列表，该列表根据节点所表示的对象之间的依赖关系正确地正确启用和禁用treeView的节点。对象列表表示构建的配置。因此，对象是组成最终产品的组件，并且对于可以为任何给定版本选择哪些组件或对象具有限制。

这是包含我要为其编写逻辑的依赖项的行的示例格式：

objectID_y1234_y1233_n2345

objectID是此对象（组件）的ID，是4位数字，在对象ID中只有一个字母的情况极少发生，例如：12a4
y1234表示此对象需要将ID为1234的对象选中才能处于活动状态。
y1233表示此对象要求选择ID为1233的对象为活动对象。

由于y1234和y1233在其ID号中使用相同的前两位数字，因此会创建or条件。

因此，此对象要求选择对象1234或1233，而不是同时选择两者。
n2345表示选择对象2345时此对象无效。


列出的第一个依赖项始终以“ y”或“ n”开头，因此您永远不能拥有objectID_1234_n2345_y1235，但是可以拥有objectID_y1234_1235_n2345。

另外，如果条件是“或”条件，则不能有y1234_n1233，要么都是y，要么都是n。

许多可能的格式中的一些：


objectID_y1234_2345
这说明对象需要选择对象1234和2345才能使该对象处于活动状态。
objectID_n1234_2345_y3456
此状态说明objectID要求不选择1234和2345并选择3456才能使该对象处于活动状态。
objectID_n1234_n1233
与y1234_y1233不同，如果使用n，则条件始终为“ and”，因此这意味着无法选择1234和1233来使该对象处于活动状态。


如果有不清楚的地方，请随时询问更多信息/解释。我试图尽可能清楚地解释这一点，因为依赖关系很容易引起混淆。我没有列出语句的所有可能组合，因为它们没有长度限制，而是由更长或多个带有对象ID的“或”和“与”条件组成。

大致情况：

我有一个objectID的树状视图，当您选择一个对象时，必须停用冲突的对象并激活或现在可以选择的对象。

依赖目的：

依赖项必须回答两个问题...

1：不能选择哪些对象来使该对象处于活动状态？

2：必须选择哪些对象才能激活该对象？

我的问题/问题：

我发现该数据非常脆弱，有时对象彼此依赖，这两个对象都无法激活，并且都无法选择。

例：

ID1234_y2345

ID2345_y1234

这不会导致1234或2345都处于活动状态，因为在开始时，由于未满足要求（相关性），因此两者均未激活。

如果有人想改变表示依赖项的语法或格式，我可以这样做。我只是还没有找到一种能满足要求而又不会造成更多复杂性或问题的替代方法。

最终，我正在寻找一种方法来解决这个问题，并提出一个可行的解决方案。我已经尝试实施解决方案已有一段时间了，到目前为止，我的所有尝试都以失败告终。我尝试了各种递归和非递归解决方案。我可能是错的，但是我几乎觉得这是神经网络可以做的事情，因为我基本上是想让计算机自己思考。

我一直试图从我需要做的所有事情的清单开始，然后实现一个满足该清单的解决方案，但最终我发现并添加到清单中时遇到了更多的问题，所以我从来没有涵盖所有的可能性。我可能还没有发现更多。总的来说，我有时能够停用和正确激活，但是它并不总是可靠的，因此需要。

电流逻辑

在树中，相同类型的组件共享相同的2个前导字符，因此，如果1234、1233和1245在组中，并且用户选择1234，则我将组视为单选按钮。因此，将1234添加到跟踪所选组件的列表中，并将1233、1245添加到另一个禁用组件列表中。然后，通过检查每个组件并确保已禁用或启用（取决于现在是否满足其要求）来更新整个树。但是，如果必须在检查时禁用另一个组件，当前我会再次检查整个树，这效率极低，因为它可能会持续一段时间。我以为递归可能会更好，但出现一团糟，这真的很难调试，但仍然有太多问题。

对于检查组件列表，我仍然认为递归是这样，因为当我选择一个组件时，我需要禁用其他不可用的组件，然后检查我禁用的组件，然后检查由于我禁用的任何组件残疾人等等...

示例：如果我禁用1234并且1890需要1234，那么我现在禁用1890。但是现在1770需要1890，所以我禁用了1770。然后，如果需要1770，则需要禁用它，依此类推...

感谢所有帮助和建议。

Answer 1

可以代替我原来的逻辑工作并实现的解决方案。

原始逻辑使应用程序检查受用户选择的节点影响的所有节点。节点状态（禁用，启用，选定）由用户选择的节点控制，并且每次用户在treeView中选择组件时都会进行验证。

解：

通过重新考虑我的方法，我为应用程序提出了以下逻辑，该逻辑完成了确保强制执行组件依赖关系的任务：

当用户选择组件时，应用程序将执行以下步骤：


检查组件中不兼容的对象，并检查用户是否选择了任何组件。


如果找到了不兼容的对象，它会通过一条信息性消息提示用户，说明用户选择了哪个组件，而该组件与用户尝试选择的组件发生冲突。

检查组件中该组件所需的其他组件，并检查是否已选择这些组件。


如果尚未选择所有必需组件，则会提示用户一条消息，指出仍需要选择哪些组件，然后将所选组件的文本变为红色，然后在treeView中将其选中。
如果满足所有要求，则选择该组件，并且如果该组件具有红色文本，则该文本将变回默认的黑色。



笔记：
这些提示是可选的，因为它们被记录在界面上的日志中，允许用户根据需要参考它们。

结论：

该解决方案允许配置器确保已满足组件的依赖性和要求。尽管更新节点是最初的意图，但我意识到在原始逻辑中，我并未想到如何帮助用户找出禁用组件的原因。使用这种新方法，配置器可以提供丰富的信息，并且不会使用户感到困惑。

当然可以像最初的概念一样创建配置器，但是鉴于我的经验和各种各样的工具，该其他解决方案提供了一个使我的用户更满意的工作应用程序。