我正在开发一个非常简单的C＃应用程序，它使用LINQ to SQL进行数据库访问。该应用程序是非Web（即胖客户端）应用程序。
我最近遇到的问题是LINQ to SQL为另一个表的外键字段创建的默认关联名称。更具体地说，我在下面提供了一个例子：
问题的例子 我使用来自参考数据表（即RefData）的值来填充我的大多数组合框，该参考数据表存储类型，描述和一些其他字段。最初加载表单时，它会使用基于类型查询的值填充组合框。例如，我有一个允许用户添加客户的表单。在这个表单上，有一个状态组合框。通过对RefData表运行查询来填充stateComboBox，其中type = stateType。然后，当用户以选择状态保存客户时，所选状态的RefData列的id存储在customer表的state列中。所有这些都按预期工作。但是，如果我的customer表有多个列是RefData表的外键，它很快就会变得非常混乱，因为LINQ创建的关联名称是Customer.RefData，Customer.RefData1，Customer.RefData2等。 ..如果我可以覆盖关联的名称，以便访问参考数据更像Customer.State，Customer.Country，Customer.Type等，那将会容易得多......
我已经考虑过在VS生成的DBML中更改此信息但是，我的数据库架构仍然非常不成熟并且经常需要更改。现在，我每隔一两天就删除DBML，以便在更改数据库后重新生成LINQ to SQL文件。是否有一种简单的方法可以创建这些关联，使用有意义的名称，这些名称在我经常重新创建DBML时不会丢失？
答案 0 :(得分：0)
我不确定LINQ to SQL是访问数据的最佳方法，期间，但我发现在你的情况下它更成问题。
你真正的问题是你的域对象的概念是相当静态的（你知道程序需要用什么来完成工作），但你不确定如何持久化数据，因为你的架构在不断变化。这不是自动更新的好方案。
如果是我，我会对域模型进行编码，这样除非您需要更改，否则它们不会更改。然后我将确定如何链接到持久模式（在这种情况下是数据库）。如果你更喜欢自动化，那么我会考虑实体框架，因为你可以先使用代码并在模式发生变化时映射到模式。
如果您发现这仍然无济于事，因为您的数据库架构更改与域模型不兼容，您需要远离编码并进入更深入的计划模式。否则，你将继续击败众所周知的变革之墙。