Multiple DBML Files - Sharing Types?
I have a Client / Server application where the client and server have shared tables (which are kept in sync as part of the application).
We currently store these tables (i.e. FileDetails) in the Shared.dbml file. So far, any stored proc that returns the result of a set of FileDetails has been pushed into Shared.dbml (even if it's just a server) SP.
I released that LINQ to SQL supports the Base Class property on DBML and I thought that maybe I might have Server.dbml that extends my Shared.dbml. In theory, this will give me a ServerDataContext with all common tables and SPs, as well as server specific items. Normally, in the SQL constructor, I would drag the SP over the FileDetails table to show that this is what was returned, however, since the class is in a different DBML, this is not possible, and in XML, I don't think ElementType IdRef = "1" would work (as the ref must point to another file)
I found that I could work around this problem by manually editing the returned XML file type:
<Function Name="dbo.SELECT_FTS_FILES" Method="SELECT_FTS_FILES">
<Return Type="ISingleResult<DataTypes.FileDetails>" />
</Function>
My question is, does anyone have experience with this approach and can point to additional resources? Are there any obvious downsides (other than manual XML updates)
All feedback is welcome
a source to share
You can inherit from your datacontext. However, in your new datacontext, you will not be able to use the linq constructor which you will have to write down manually.
Is there any reason you don't want to use two datacontext?
Inheritance and LinqToSql don't play together at all. If you have a big need for this, you should look into another ORM like NHibernate.
a source to share