0

在微软开发环境中，即。.net、c#、sql server、实体框架等：对于由于业务需求而频繁向底层数据库中的表添加表和列的应用程序，最佳设计是什么。

在这种情况下使用 ORM/Entity 框架的问题在于，您必须更新模型、重新编译和重新部署应用程序，这可能会很痛苦 + 如果添加这些新列需要简单到复杂的数据验证，那么您有还要在正确的地方仔细编写代码。

只是想找出是否有一种简单有效的方法来使用 ORM 的强大功能，而不是为每一件小事都创建 SP。

同一问题的第 2 部分：

为什么我不能告诉 ORM 我想使用这些表（或整个数据库），然后它会在运行时生成类。我知道事情不会因此而被强类型化。最大的一个缺点是设计时/编译时错误不会像在强类型设计中那样发生，这会迫使您编写更少的错误代码（或至少因此节省大量时间）。

但这至少会解决以下问题：

  • 它将从 db 中获取所有列（包括新列）
  • 你不必编译，部署因为小的变化

现在，如果有一种简单的方法可以使用 ORM 或有助于这种设计的东西来实现一个好的设计，请告诉我。建议将不胜感激。

4

2 回答 2

4

正如您所建议的那样，数据库模式的不断扩展使其成为维护噩梦。而是考虑采用垂直方法。例如，设想一个模式映射表，其中每个新记录代表该实体的一个新属性。每当需要一个新属性（本质上是水平表结构上的一个新列）时，它就被简单地创建为一个新记录。

PropertyID(PK)      PropertyName
1                   ID
2                   Name
3                   Description
4                   LastModDate

第二个表将保存实体实例记录

InstanceID      PropertyID(FK)  PropertyValue
1               1               1
1               2               Target Field
1               3               Minnesota Twins baseball stadium
1               4               1/15/2013 12:00:00 PM

然后，您的 C# 模型将保存代表实体实例的通用属性对象列表。特定实体的属性列表及其值将在运行时从实体的实例记录中填充。

public class EntityInstance
{
    public int InstanceID { get; set; }
    public List<InstanceProperty> Properties { get; set; }
}

public class InstanceProperty
{
    public int PropertyID { get; set; }
    public string PropertyName { get; set; }
    public object PropertyValue { get; set; }
}

这种方法可以扩展您的数据模型架构，而无需不断地重新生成实体，或者更糟糕的是，每次都向您的托管代码添加特定的新属性以使用它们。

我们非常成功地为我们庞大的产品线实施了一个高度可配置的规则引擎，然后驱动了整个公司使用的多个独立应用程序的选项、工作流程和行为。我上面的例子有点陈词滥调，但它们有助于说明这一点。

同样，关键是“垂直”而不是“水平”思考。

于 2013-01-16T05:55:29.480 回答
-1

在这样的环境中尽量保持每个表独立，我的意思是表之间没有很多关系。我们也面临同样的问题，为此我们遵循 AGILE 方法。此链接将帮助您 敏捷地进行更改

于 2013-01-16T05:55:33.740 回答