模型绑定器中的模型绑定

首先,在这里忍受我.我有一个自定义模型绑定器,它成功地将表单数据映射到自定义对象.在此模型绑定器中,它还将表单项映射到不同的自定义对象.我觉得我应该做的是创建一个单独的模型绑定器来处理第二个映射.这是一个简化版本.

自定义对象:

public class Category
{
    public int CategoryId { get; set; }
    public string Name { get; set; }
    public string Status { get; set; }
    public string Description { get; set; }
    public IEnumerable SubCategories { get; set; }
}

public class SubCategory
{
    public int CategoryId { get; set; }
    public string Name { get; set; }
    public string Description { get; set; }
    public string Status { get; set; }
}

如果我的表单为SubCategories传回了一堆ID,那么我需要做的就是运行到数据存储库并为SubCategory对象加水.从表单中,将按以下格式提交子类别列表:

    Something
    Something else




    Something
    Something else




    Something
    Something else

编写一个自定义来映射类别显然很简单,编写模型绑定器,然后映射SubCategory(在模型绑定器中我将运行查询我的数据存储库)证明有点困难.

我不清楚我是多么清楚,道歉,感谢阅读,如果有什么我可以说的话让我更清楚,请告诉我!

我对此的看法是模型绑定器应该构建表示模型,而不是存储库中的实体类型.模型绑定器应该是从表单的键/值集合到表示模型的非常简单的映射,该表示模型主要是标量值,可能与其他类型(通常是标量值或列表)有某种关系.正如您所发现的那样,必须从存储库中实现实体实例会增加许多复杂性.

而且,这是不必要的.使用演示模型具有许多优点,包括:

由于演示模型仅包含这些字段,因此无需将用户允许更新的字段列入白名单.

默认模型绑定器适用于除最复杂的模型绑定方案之外的所有方案.在实践中,我发现当用户看到的值必须以条件方式绑定到某个其他值时,我只需要使用自定义模型绑定器.使用演示模型时,演示模型的结构应与页面结构相匹配,因此出于结构原因,您无需使用自定义模型绑定器.

在创建数据库或实体模型之前,您将能够创建视图和控制器.这意味着在完成大量工作以创建最终系统之前,您可以让客户购买您的设计.这有助于在实体模型发生之前解决结构问题.只需创建一个与您认为客户想要查看的页面相匹配的演示模型,使用此演示模型的组合实例构建页面的大致轮廓,并将其显示给客户.如果他们很高兴,您可以构建存储库/实体模型并编写LINQ查询以将其映射到您的表示模型.

因此,在您的示例中,子类别将从表单集合作为整数列表进入.因此,表示模型应该具有相同的整数列表.在控制器中,绑定后,您可以调用方法将模型值从表示模型传输到存储库中的物化类别实例.