我正在努力的事情,我认为更具哲学性的是DropDownList项(或实际上任何类型的选择列表项)是否应该是模型的一部分,或者它们是否应该硬编码到UI或业务层中。或者这可以很好地利用ViewModel?
对于某些类型的下拉列表,您显然必须将它们作为模型的一部分。例如,模型必须生成与客户关联的订单ID的下拉列表。
其他种类,我称之为“查找”数据对我来说不太清楚。例如,性别。为什么强制往返查找以填充包含2个项目的字段?也许这是不成熟的优化,但是如果你有50个字段,这就是为了填充一个页面而进行的大量往返。当然,缓存可能在那里派上用场,但看起来很糟糕。
我还担心将所有这些查找列表添加到模型中会不必要地混淆它。特别是如果你有很多。
还可以选择在UI中不进行硬编码,但在业务层中进行硬编码。可能甚至创建一个除了填充这些数据之外什么都不做的课程。
如果答案是,您仍然应该将它们作为数据模型的一部分,那么您的数据模型是否应该为每组查找字段设置不同的表格。如果您的数据模型有200或300个这样的字段,那就是200或300个表,这确实使维护数据模型变得更加复杂。
我问了一个问题,关于在一段时间内有一个共同的查询表,并且一致认为这是一个坏主意。但对于存在大量领域的数据量很大的应用程序,我发现自己很怀疑。
现在,我知道很多人会说“这取决于”,但我正在寻找一种“一般”的答案。一般来说,这里的经验法则是什么?
答案 0 :(得分:2)
我一直在参与构建一个包含大量词典的系统。它们中的大多数存储在一个简单的表中,其中包含字典的id,项的id,名称和一些其他基本值。此表中的某些项目具有预定义的ID(例如male = 1001,female = 1002),因此如果table具有gender_id字段,我不必在字典表中进行查找以搜索male,我知道它的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)加载项目的增量搜索。
答案 1 :(得分:1)
我要改述你的问题。该模型是模型。如果替代品的集合是模型的一部分,那么无论如何它们都是模型的一部分。无论实施方式如何,数据模型都具有内部一致性和完整性。
那么问题就变成了,模型中包含的各种替代方案是否应该作为下拉列表实现?我的回答是肯定的,有时候。
关于“性别”这样的案例,问题是“在不久的将来,有多少可能会增加这类性别?”如果很有可能,你可能最好还是为往返付费。如果机会为零,那么最好将选择硬编码到UI中。
多年前,我会说,对男性,女性这一集的补充是完全不可能的。今天,有些人有不同的看法。
答案 2 :(得分:0)
如果您有一个大型列表并需要在服务器上动态过滤它,那么您需要对您的Action进行ajax调用。
如果你想用一堆选项渲染一个select,或者你只想在客户端过滤一个json数组值,那么我建议你在ViewModel中添加下拉项并在Controller中填充这个集合。该列表可能暂时硬编码,但您可以稍后通过修改控制器而不触及ViewModel或UI来使其动态化(即从数据库中读取)。
查看此链接以获取一些代码示例: http://odetocode.com/blogs/scott/archive/2010/01/18/drop-down-lists-and-asp-net-mvc.aspx