DropDownList 项目是否应该成为模型的一部分？

发布于 2024-10-17 06:43:00 字数 699 浏览 5 评论 0原文

我认为，从更哲学的角度来说，我正在努力解决的问题是 DropDownList 项（或实际上任何类型的选择列表项）是否应该成为模型的一部分，或者是否应该将它们硬编码到 UI 或业务层中。或者这也许是 ViewModel 的一个很好的用途？

对于某些类型的下拉列表，您显然必须使它们成为模型的一部分。例如，模型必须生成与客户关联的订单 ID 的下拉列表。

其他类型（我将其称为“查找”数据）对我来说不太清楚。例如，性别。为什么强制进行往返查找以用 2 个项目填充字段？也许这是不成熟的优化，但如果您有 50 个字段，那么仅仅为了填充一页就需要进行大量的往返。当然，缓存可能会派上用场，但它看起来很笨拙。

我还担心将所有这些查找列表添加到模型中会不必要地使其混乱。特别是如果你有很多的话。

还可以选择不在 UI 中进行硬编码，而是在业务层中进行硬编码。甚至可能创建一个除了填充这些数据之外什么也不做的类。

如果答案是，您仍然应该将它们作为数据模型的一部分，那么就存在您的数据模型是否应该为每组查找字段使用不同的表的问题。如果您的数据模型有 200 或 300 个这样的字段，那就是 200 或 300 个表，这确实使维护数据模型变得更加复杂。

不久前我问了一个关于拥有一个通用查找表的问题，大家一致认为这是一个坏主意。但对于有很多字段的数据量很大的应用程序，我发现自己很怀疑。

现在，我知道你们很多人会说“这取决于”，但我正在寻找“一般”的答案。一般来说，这里的经验法则是什么？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

御弟哥哥 2024-10-24 06:43:00

我一直在参与构建一个包含大量词典的系统。大多数数据都存储在一张简单的表中，其中包含字典的 id、项目的 id、名称和其他一些基本值。该表中的某些项目具有预定义的 ID（例如，男性 = 1001，女性 = 1002），因此如果表具有性别 ID 字段，我不必在字典表中查找来搜索男性，我知道它的 id。这些 id 仍然在代码中定义为常量，但出于演示目的，它们是从数据库中获取的。它运行良好，性能也不错（数百个词典，数千个项目）。它们可以传递到视图模型中的视图。用于编辑人员的视图模型可能如下所示：

public class PersonViewModel {
    public Person Person { get; set; };
    public SelectList Genders { get; set; };
    public SelectList Departments { get; set; };
    public SelectList Positions { get; set; };
}

您可以使用代码填充视图：

Genders = DictionaryService.GetDictionary(Dictionaries.Genders);
Departments = DictionaryService.GetDictionary(Dictionaries.Departments);
Positions = DictionaryService.GetDictionary(Dictionaries.Positions);

其中 Dictionaries 是枚举。

在 DictionaryService.GetDictionary() 方法中，您可以引入某种缓存。

如果您想填充下拉列表，该下拉列表可以具有无限数量的项目（对于引用其他表的字段，这些字段会随着时间的推移而增长很多），请使用某种带有动态（ajax）加载项目的增量搜索。

I've been participating in building one system with a lot of dictionaries. Most of them were stored in one simple table, which contained id of dictionary, id of item, its name and some other basic values. Some of the items in this table had predefined ids (for example male = 1001, female = 1002), so if table had gender_id field, I didn't have to make a lookup in dictionary table to search male, I knew its id. These ids were still defined in code as constants, but for presentation purposes, they were taken from database. It worked well and performance was not bad (hunderds of dictionaries, thousands of items). They could be passed to view in view model. View model for editing person could look like:

public class PersonViewModel {
    public Person Person { get; set; };
    public SelectList Genders { get; set; };
    public SelectList Departments { get; set; };
    public SelectList Positions { get; set; };
}

You could populate view with code:

Genders = DictionaryService.GetDictionary(Dictionaries.Genders);
Departments = DictionaryService.GetDictionary(Dictionaries.Departments);
Positions = DictionaryService.GetDictionary(Dictionaries.Positions);

where Dictionaries is enum.

In DictionaryService.GetDictionary() method you can introduce some kind of caching.

If you want to populate dropdown, that can have unlimited number of items (for fields, that have reference to other tables, that grow a lot in time), use some kind of incremental search with dynamically (ajax) loaded items.

回复收藏 0 原文

赢得她心 2024-10-24 06:43:00

我要重新表述你的问题。模型就是模型。如果替代方案的集合是模型的一部分，那么无论如何它们都是模型的一部分。无论如何实现，数据模型都具有内部一致性和完整性。

那么问题就变成了，模型中包含的替代方案集是否应该作为下拉列表来实现？我的回答是，有时是的。

对于像“性别”这样的情况，问题是“在不久的将来增加性别集合的可能性有多大？”如果可能性很大，您最好支付往返费用。如果机会为零，您最好将选择硬编码到 UI 中。

几年前，我会说添加[男，女]套装是完全不可能的。今天，有人持不同的看法。

回复收藏 0 原文

贱贱哒 2024-10-24 06:43:00

如果您有一个很大的列表并且需要在服务器上动态过滤它，那么您需要对您的操作进行 ajax 调用。

如果您想使用一堆选项或只是一个 json 值数组来渲染选择，您将在客户端过滤这些值，那么我建议将下拉项添加到您的 ViewModel 中并在 Controller 中填充此集合。该列表可能暂时是硬编码的，但稍后您可以通过仅修改控制器而不触及 ViewModel 或 UI 来使其动态化（即从数据库读取）。

查看此链接以获取一些代码示例：
http:// /odetocode.com/blogs/scott/archive/2010/01/18/drop-down-lists-and-asp-net-mvc.aspx

回复收藏 0 原文

~没有更多了~