Question

我们目前有一个应用程序，它有一个只有静态数据的大型数据库（readonly）。

我们正在考虑以编译程序集的形式部署数据，其中模型对象构造为填充集合。一个简单的例子：

public Model()
{
    this.Property1 = new List<AClass>();
    this.Property1.Add(new AClass(1,2));
    this.Property1.Add(new AClass(4,3));
    this.Property1.Add(new AClass(2,6));
}

人们主要担心的是他们从未见过有人这样做过。你以前见过/使用过这种方法吗？

主要好处是您不再需要数据访问层，而且性能更快。

编辑：readonly数据库当前由工具生成，因此代码也将由工具生成。

Answer 1

我已经嵌入了数据，否则这些数据会多次存在于应用程序的数据库中。没有XML文件，没有纯文本文件，没有数据库。

我通常只针对少量我认为永远不会改变的数据。

原因总是懒惰。我不想创建数据库，模式，编写数据访问代码等。在这些情况下，即使制作XML文件对于少量数据也是太多工作。

如果所有数据都是只读的，我认为部署程序集而不是实际数据库是一个有趣的想法。正如你所说，它消除了一个非常可能存在问题的依赖。

我唯一能想到的缺点是，当你进行查询时，程序集可能需要将大量数据加载到内存中。只要你有某种延迟加载功能，我认为它会很好用。

Answer 2

实际上它们是两种不同类型的列表：

数据列表/主数据

这是存储在数据库中的列表。通常，列表很大，对代码逻辑的影响很小。例如，国家/国家，字体列表等。这应该放在数据库中。如果对代码逻辑有影响（例如，如果国家是美国，然后显示Zip框），则应将配置放在数据库（例如IsShowZip）。如果存储在应用程序/程序集中，这没有任何好处。
应用程序列表

这是一个对代码逻辑影响很大的列表。通常它会显着影响业务流程（工作流），或者具有特定的数据库架构。例如，支付类型信用卡/互联网商务，如Paypal。它会影响工作流程（如果来自paypal可能需要等待来自那里的验证）和输入（信用卡号/ paypal号码）。如果存储在数据库中，这只有一个好处，因为它可以作为输入的约束（因此除了Paypal中的Credit Card / Payment Type之外，它不会是其他值。但是，它取决于您的数据库访问方式，它可以在应用程序和数据库之间创建隐藏的依赖关系。

更新：

我错过了readonly database部分。为了说清楚，有使用readonly database参考上面第1点的缺点和专业人士：

的优点：

可以利用索引和查询优化。这适用于过滤数据
如果数据库是集中的或使用服务器 - 客户端体系结构（可能在此问题中不适用），则可以修改数据库而无需更改每个客户端
不提供更新数据的代码修订历史记录。

缺点：

对数据库进行查询时的开销（性能影响）。
额外可避免的依赖 - （YAGNI - 你不需要它）

将大量静态数据列入代码而不是数据库？

2 个答案: