由sprocs支持的Asp.Net MVC应用程序的结构变化

Question

Hello开发人员。

首先，我事先为下面的文字墙道歉，但是经过一天疯狂之后，我需要求助。

我偶然发现了一个似乎无法解决的问题。我将尝试以最佳方式描述场景。

手头的任务：在现有的Asp.Net Mvc应用程序中，为整数字段创建一个查找表，并使用编辑视图中查找的文本值。保存时，我们必须首先检查查找是否已具有相同Root ID的相应文本值。如果有，请使用它。否则，创建它然后使用它。

结构：

数据模型是一个对象图，其中我们有根对象，一个A级子对象的集合，每个级别一个子对象都有一个B级子对象的集合，所以像这样：

• 根（带字段）
  • 等级A子（带字段）x n
    • B级儿童（带字段）x n

我们必须处理的字段位于LevelB对象上。

有一个Mvc视图可以处理整个数据。对于集合对象，所有字段都命名为levelA1levelB1MyField，levelA1levelB2MyField等，因此每个字段在帖子中都有唯一的名称。当帖子发生时，所有值都通过formCollection参数读取，该参数具有平均120/130个键。通过拆分键并在名称的数字部分循环来隔离键，读取值并将其解析为预期类型并分配给对象图。

支持对象图的数据层部分是所有存储过程，并且所有映射（对象到sproc和sproc到对象）都是手写的。读取部件有一个存储过程，它获取多个数据集，调用它的方法读取数据集并创建对象图。

对于保存，有多个sprocs，主要是“CreateRoot”和“UpdateRoot”。当代码必须执行此类任务时，会发生以下情况：

• 对于创建场景，调用“CreateRoot”，然后为图中的每个元素循环调用sprocs“CreateLevelA”和“CreateLevelB”;
• 对于更新方案，调用“UpdateRoot”，在内部删除所有“LevelA”和“LevelB”项，然后代码重新创建它们，循环调用前面提到的sprocs。

最后一条有用的信息是“业务对象图”直接用作视图中的视图模型，而不是映射到普通的“html友好”视图模型。这可能是导致我最麻烦的原因。

所以现在视图上的文本框处理一个“整数”字段。该字段现在必须接受一个字符串。 LevelB上的字段必须保持整数，只能使用查找表（当然是FK），并且必须使用查找中的文本字段。

我试过的方法没有成功：

• 我的第一个想法是将属性MyField上的数据类型从整数更改为对象上的字符串，然后相应地更改sprocs并处理sproc级别的连接：我的视图中有一致的对象，并且读/写sprocs可以从字符串转换为整数，反之亦然，但我不能这样做，因为在写入时检索整数的连接键是Root项的一部分（正如我在第一篇中所述）我不知道在CreateLevelB sproc中，并且更改整个调用链以传递这些参数会对应用程序的其余部分产生巨大影响，因此没有好处。
• 我的下一个尝试是保持“按原样”并调用一些“翻译方法”：在阅读时，将整数传递给视图，然后调用翻译方法来显示文本值。保存时，使用发布的文本检索整数。保存部分可以工作，我有我需要的所有参数，但是对于读取部分，我必须实例化“数据访问层”并在View级别调用它的方法，并且没有必要解释为什么是一个非常糟糕的选择，所以我也排除了它。

现在我没有选择（或者无论如何都是想法）。任何解决这个问题的建议都是非常受欢迎的，如果有什么不明确的地方，请指出它，我会用更准确的信息编辑我的帖子。

感谢。

Answer 1

这不是一个真正的答案，但你可以撕掉所有的sprocs并使用OR映射器的更新工具。这将解决所有分层问题。您只需更新数据，并在最后提交。

我想这也会使“我应该使用int还是字符串”的问题消失了。

编辑：在阅读您的评论后，我想到了以下内容：不要实现替代方案1.您宁愿牺牲视图中的代码质量而不是数据存储模型。最后一个更重要，更集中使用。

我不会太担心通过调用DAL等来搞乱视图。视图中的更改是本地化的，不会弄乱应用程序的体系结构。它们只会降低视图质量。

也许您可以在控制器中创建视图模型并在DAL模型和视图模型之间进行转换？或者这种模式不被允许？