从这里我可以对这些关联进行任何更改:我可能希望关联的父端是内部的而不是公共的,这样JSON序列化器(比如说)就不会被循环引用捕获;或者在Form和FormAnswer表之间的连接中,我可能希望将child属性称为Answers而不是机器生成的FormAnswers.
现在,如果更改了数据库设计,并且我想更新DBML以反映此更改,那么这些自定义似乎需要我跟踪每个更改并手动更新它(添加属性,设置它的源,源数据类型,C#数据类型…)
这可能是一个相当繁琐的过程;我要问的是,是否有任何方法可以实现自动化.
1.我可以在sql服务器上反映这些更改吗?
看来,理想的解决方案是,如果有任何方法可以直接在sql Server数据库图表中制作这些规范,那么完全重新生成DBML文件(删除所有内容并将其拖到DBML编辑器上)将会得出完全相同的结果.
怀疑我已经知道上述情况,如果可以实现,我很乐意和解:
2.我可以将这些更改提取到自己的类中吗?
由于所有Linq to sql实体都是作为部分类生成的,我想了一段时间我可以创建一个新文件,我手动维护,我可以将所有更改复制到所提到的文件中.
所以每当我改变一个关联时,我会深入研究designer.cs代码,剪切修改后的关联,并将其粘贴到我自己的文件中.在重新生成时,我会期望任何重复的编译器错误,并轻松地逐步执行并从DBML中删除这些关联.这里的问题是关联似乎只是属性的属性.如果Form有一个名为Answers的属性,并且DBML生成器将尝试创建一个名为FormAnswers的属性,则生成的Form对象将只具有这两个属性,这根本不是我想要的.
有没有人对这些解决方案有任何好运?或者,如果您知道处理问题的任何其他方式,我愿意接受建议.
解决方法
至于FK =>你提到的关联问题:同步选项允许你排除所有或individual child navigation properties,以避免在序列化实体对象时可能导致麻烦的循环引用.
如果您想将其用于测试旋转,可以从http://www.huagati.com/dbmltools/下载该加载项.
excluding one side of a FK association http://forum.huagati.com/upload/2/exclusionChdProp.png