我有一个客户端/服务器应用程序,其中客户端和服务器有一些公共表(作为应用程序的一部分保持同步)。
我们目前将这些表(即FileDetails)存储在Shared.dbml文件中。到目前为止,任何返回FileDetails集合结果的存储过程已被放置在Shared.dbml(即使它只是一个服务器)SP中。
我发布LINQ to SQL支持DBML上的Base Class属性,我想也许我可以有一个Server.dbml,它扩展了我的Shared.dbml。从理论上讲,这将为我提供一个ServerDataContext,其中包含所有共享表和SP,以及特定于服务器的元素。通常在SQL设计器中我会拖放SP,在FileDetails表上显示这是返回的内容,但是由于该类在不同的DBML中这是不可能的,而在XML中我不认为ElementType IdRef =“1”方法将起作用(因为ref需要指向另一个文件)
我发现我可以通过手动编辑XML返回类型来解决这个问题:
<Function Name="dbo.SELECT_FTS_FILES" Method="SELECT_FTS_FILES">
<Return Type="ISingleResult<DataTypes.FileDetails>" />
</Function>
我的问题是,有没有人有这种方法的经验,可以指出我更多的资源?是否有任何明显的缺点(除了手动XML更新)
欢迎所有反馈
答案 0 :(得分:2)
您可以从datacontext继承。但是,在新的datacontext中,您将无法使用linq设计器来手动编写代码。
你有什么理由不想要两个datacontext吗?
继承和LinqToSql一般不能很好地协同工作。如果你非常需要它,你应该研究另一个像NHibernate这样的ORM。