在 ASP.NET MVC 中创建具有多个下拉列表和文本字段的大型表单

Question

在我继续使用 ASP.NET MVC 的过程中，我现在需要为实体呈现编辑/创建表单。

我的实体由枚举和一些其他模型组成，通过 LINQtoSQL 在存储库中创建。

我现在正在努力寻找一种体面的方式来呈现编辑/创建表单，该表单将包含一些下拉列表和一些文本字段。我意识到这可能不是最用户友好的方法，但这是我现在要做的:)。

我有一个存储库层和一个业务层。控制器与服务层接口。

最好像这样简单地创建一个视图模型吗？

public class EventFormViewModel
{
    IEventService _eventService;

    public IEvent Event { get; private set; }

    public IEnumerable<EventCampaign> Campaigns { get; private set; }
    public IEnumerable<SelectListItem> Statuses { get; private set; }
    // Other tables/dropdowns go here

    // Constructor
    public EventFormViewModel(IEventService eventService, IEvent ev)
    {
        _eventService = eventService;
        Event = ev;

        // Initialize Collections
        Campaigns = eventService.getCampaigns().ToSelectList(); //extn method maybe?
        Statuses = eventService.getStatus().ToSelectList();  /extn for each table type?
    }

所以这会给我一个新的 EventFormViewModel 我将绑定到一个视图。但这是最好的方法吗？我基本上是从数据库中提取几个不同表的所有数据并将它们转换为 IEnumerable。这似乎效率不高，但我想我可以缓存下拉列表的内容。

另外，如果我只有获取下拉菜单数据的方法，我应该跳过服务层直接进入存储库吗？

我的问题的最后一部分：对于 ToSelectList() 扩展方法，是否可以为每个表编写一个方法并通用使用它，即使某些表具有不同的列（“Id”和“Name”与“ Id”和“CampaignName”）。

如果这太笼统了，请原谅我，我只是想避免走上一条死胡同——或者一条会有很多坑洼的路。

Answer 1

我会说，如果您正在考虑“跳过”一个层，那么您还没有真正准备好使用 MVC。层的全部意义，即使它们很薄，也是为了促进单元测试并尝试强制分离关注点。

至于泛型方法，有什么理由可以只使用 OOB 对象，然后在它们无法满足您的需求时扩展它们（使用扩展方法）？

Answer 2

我不会为我的视图模型对象提供 IEventService。我更喜欢将视图模型对象视为一个哑数据传输对象。我会让控制器负责向 IEventService 询问数据并将其传递给视图模型。

我基本上会提取所有数据 从数据库返回一些 不同的表并转换它们 到一个 IEnumerable

我不明白为什么这会效率低下？您显然不应该从表中提取所有数据。像往常一样执行您需要在数据库中执行的过滤和加入。将结果放入视图模型中。

另外，如果我只有方法 获取下拉数据，我应该只是 跳过服务层，直接进入 仓库？

如果您的应用程序非常简单，那么服务层可能是不需要的抽象/间接层。但是，如果您的应用程序有点复杂（根据您上面发布的内容，我猜是这种情况），请考虑通过走捷径并直接进入存储库并将其与您将获得的结果进行比较如果您使用服务层，则可维护性和可测试性。

你能做的最糟糕的事情是，只有当你觉得有需要时才通过服务层，而当服务层不提供任何额外的逻辑时，直接进入存储库。无论你做什么，都要保持一致（这几乎总是意味着：通过一个服务层，即使你的应用程序很简单。它不会保持简单）。