如何覆盖默认LINQ到SQL关联名称

我正在开发一个非常简单的C#应用程序，它使用LINQ到SQL进行数据库访问。该应用程序是一个非web（即胖客户端）应用程序

我最近遇到的问题是LINQ to SQL为另一个表的外键字段创建的默认关联名。更具体地说，我在下面提供了一个示例：

问题实例 我的大多数组合框都是使用参考数据表（即RefData）中的值填充的，该表存储类型、说明和一些其他字段。当表单最初加载时，它会根据类型查询将值填充到组合框中。例如，我有一个表单，允许用户添加客户。在这个表单上，有一个状态组合框。stateComboBox通过对RefData表运行查询来填充，其中type=stateType。然后，当用户使用选定状态保存客户时，选定状态的RefData列的id存储在客户表的state列中。所有这些都如预期的那样起作用。但是，如果我的客户表中有多个列是RefData表的外键，则很快就会变得非常混乱，因为LINQ创建的关联名称是customer.RefData、customer.RefData1、customer.RefData2等。。。如果我可以覆盖关联的名称，这样访问参考数据就更像Customer.State、Customer.Country、Customer.Type等，那就容易多了

---

我已经研究过如何在VS生成的DBML中更改这些信息，但是，我的数据库模式仍然非常不成熟，需要不断地进行更改。现在，我每一两天就删除一次DBML，以便在更改数据库后重新生成LINQ to SQL文件。有没有一种简单的方法可以用有意义的名称创建这些关联，而在我频繁地重新创建DBML时，这些关联不会丢失？

我不确定LINQ to SQL是访问数据的最佳方法，period，但我发现在您的情况下，它的问题更大

您真正的问题是您的域对象的概念是相当静态的（您知道程序需要使用什么来完成工作），但是您不确定如何持久化数据，因为您的模式在不断变化。这不是automagic更新的好方案

如果是我，我会对域模型进行编码，这样它们就不会更改，除非您希望更改。然后，我将决定如何链接到持久模式（本例中为数据库）。如果您喜欢更多的自动化，那么我将考虑实体框架，因为您可以首先使用代码，并在其更改时映射到架构。

---

如果您发现这仍然没有帮助，因为您的数据库模式更改与域模型不兼容，那么您需要远离编码，进入更深入的规划模式。否则，您将继续与众所周知的变革之墙搏斗。

谢谢，我已经简要介绍了Entity框架，因为我们这里有一位开发人员正在将其用于移动网站。我可能夸大了域模型的变化频率。所有的域对象都定义得很好，但是，我继承了这个项目，并且被给予了一个非常严格的期限。最后，我主要需要对某些列上的数据类型进行轻微调整，并在必要时添加外键。我是LINQ和.NET的新手，我确信有更好的设计。现在，我正在将存储库模式用于DAOs@Grasshopper：repository是一个不错的模式，但我真的很喜欢巩固我的域模型和映射，而不是使用automagic LINQ到SQL位来进行映射。有一些可爱的方法（在某些情况下是kludges）覆盖部分类中的一些位，这样regen就会破坏部分类（不会编译），而不是破坏您的域模型，所以LINQ to SQL也有一些方法。无论您是否夸大了更改，这显然是一个痛点，当您有很多代码依赖于特定的命名，并且自动控制位使其变得更糟时，这是很常见的。谢谢，我现在回顾一下域模型。我曾经使用Java和Hibernate，在那里我们手动创建映射文件。我已经知道了如何命名对其他表的引用，但是，正如您所说，我认为我最大的担忧是，这是否是最优雅的设计，并且担心在数据库必须更改的任何时候，自动生成都会导致对映射文件进行大量的重新工作。